Der rel=”canonical”-Tag informiert Suchmaschinen darüber, “**welche URL die kanonische Version dieses Inhalts ist**”, um die Verteilung der Gewichtung zu vermeiden.
Im Google SEO wird dies durch Hinzufügen von <link rel=”canonical” href=”kanonische URL”> in den <head>-Bereich der Seite erreicht.
Daten zeigen, dass E-Commerce-Websites, die den Canonical-Tag korrekt implementieren, ihre Indexierungsrate für Produktlistenseiten um durchschnittlich 28% erhöhen und das Crawl-Volumen für doppelte URLs um 40%-60% reduzieren konnten.
Nachrichten-Websites, die ähnliche Artikel über den kanonischen Tag konsolidierten, verzeichneten einen durchschnittlichen Anstieg der Suchklicks auf den Hauptinhalt um 19%.
Allerdings ergab eine tatsächliche Umfrage, dass nur 31% der Websites diesen Tag zu 100% korrekt verwenden (häufige Fehler sind die Weiterleitung auf fehlerhafte URLs, die Nichteinhaltung von Protokoll-/Domain-übergreifenden Standards, die Überlagerung mehrerer Tags usw.).
Gründe für die Verwendung des Canonical-Tags
Bei der täglichen Datenverarbeitung von Google-Suchmaschinen haben über 65% der Websites Probleme mit doppeltem Inhalt, die durch eine unangemessene URL-Struktur verursacht werden.
Dies äußert sich in folgenden Formen:
- Derselbe Artikel ist über Adressen mit dynamischen Parametern (z. B. ?utm_source=xxx) zugänglich.
- Vorhandensein von Verzeichnis-Endungen (z. B. /seite/ und /seite/index.html).
- Unterschiedliche Subdomains (z. B. www und non-www).
John Mueller von Google hat in offiziellen Q&A-Sitzungen mehrfach erwähnt, dass Suchmaschinen, wenn sie feststellen, dass “mehrere URLs sehr ähnliche oder identische Inhalte anzeigen”, vor der Schwierigkeit stehen, zu entscheiden, “**welcher URL die Gewichtung zugewiesen werden soll**”.
Eine einzige E-Commerce-Produktseite kann aufgrund von Farbfilterung oder Sortierparametern über zehn verschiedene URLs generieren; eine Pressemitteilung kann in mehrere Spalten geschoben werden, was zu mehreren Eingangslinks führt.
Durch die Verwendung des Canonical-Tags wird der Suchmaschine klar mitgeteilt: “**Obwohl dieser Inhalt über mehrere Adressen sichtbar ist, konzentrieren Sie bitte die Gewichtung und das Ranking nur auf diese von mir festgelegte URL.**”
Wie beeinflusst doppelter Inhalt SEO?
Doppelter Inhalt selbst führt nicht direkt zu einer Suchmaschinenstrafe (Google hat klargestellt, dass es “**Websites nicht allein wegen doppelter Inhalte bestraft**”), führt jedoch zu einer **Verteilung der Gewichtung**.
Wenn derselbe Inhalt über mehrere URLs zugänglich ist, betrachtet die Suchmaschine diese URLs als “**separate Seiten**” und verarbeitet sie einzeln.
Zum Beispiel ist ein Originalartikel über die folgenden vier URLs zugänglich:
https://beispiel.de/artikelhttps://beispiel.de/artikel?quelle=newsletterhttps://beispiel.de/artikel#kommentarehttps://www.beispiel.de/artikel(die www-Version)
Ohne eine kanonische Angabe crawlt die Suchmaschine möglicherweise alle vier URLs gleichzeitig und berechnet das Indexierungsgewicht für jede einzelne.
Da das Suchbedürfnis des Benutzers jedoch **grundsätzlich nur eine einzige Antwort** erfordert, könnte das Ranking aller vier Versionen am Ende insgesamt niedrig sein (aufgrund der Gewichtsverteilung), oder nur eine davon wird zufällig indiziert, während die **anderen Versionen lange Zeit im Status “nicht indiziert” oder “niedriges Ranking” verharren**.
Auf einer E-Commerce-Website kann eine einzige Produktdetailseite aufgrund von Parametern (wie ?größe=XL, ?farbe=rot) durchschnittlich 8-12 doppelte URLs generieren. Das Crawl-Volumen für diese Seiten kann 15%-20% des gesamten Crawl-Budgets ausmachen (das stattdessen für neue, wertvollere Seiten verwendet werden sollte).
Bei Nachrichten-Websites, bei denen Inhalte in mehrere Spalten (z. B. “Neueste Nachrichten”, “Industrietrends”, “Empfohlen”) geschoben werden, kann ein einzelner Artikel 3-5 verschiedene Eingangs-URLs generieren.
Konkrete Fallstudie: Eine mittelständische E-Commerce-Website hatte vor der kanonischen URL-Festlegung eine Indexierungsrate von nur 62% für Produktlistenseiten (d. h. nur 62 von 100 Seiten wurden von Google indiziert und konnten am Ranking teilnehmen).
Nach dem Hinzufügen des kanonischen Tags für parametrisierte Listenseiten (z. B. ?kategorie=schuhe&sortieren=preis) (Weiterleitung auf die nicht parametrisierte Basis-URL wie /schuhe) stieg die Indexierungsrate drei Monate später auf 81%, und der organische Suchverkehr für die entsprechenden Produkte stieg um 17%.
Nicht “Duplikat entfernen”, sondern “autoritative Version festlegen”
Viele Webmaster missverstehen den Canonical-Tag und glauben, er diene dazu, “**doppelte Seiten zu eliminieren**”.
Tatsächlich besteht seine Hauptfunktion darin, “**der Suchmaschine mitzuteilen: Welche URL soll in den Suchergebnissen indiziert, gespeichert und mit besonderem Ranking-Gewicht versehen werden, wenn derselbe Inhalt über mehrere URLs verfügbar ist?**”
Wenn Sie den folgenden Code in den <head>-Bereich einer Seite einfügen:
<link rel=“canonical” href=“https://beispiel.de/kanonische_URL” />
Senden Sie der Suchmaschine ein klares Signal: “Obwohl dieser Inhalt auch über diese Seite erreichbar ist (z. B. die parametrisierte /artikel?quelle=e-mail), möchte ich, dass Sie das Gewicht und die Ranking-Chancen auf **diese kanonische URL https://beispiel.de/** konzentrieren.”
Basierend auf der offiziellen Dokumentation von Google und der Beobachtung tatsächlicher Crawl-Daten:
- Crawl-Seite: Die Suchmaschine crawlt weiterhin alle Versionen der Seite (einschließlich parametrisierter URLs und Verzeichnisse), verwendet jedoch den kanonischen Tag als Referenz, um die “Wichtigkeit” dieser Seiten anzupassen. Zum Beispiel kann eine parametrisierte URL gecrawlt werden, aber der Crawler wird sie weniger häufig erneut besuchen oder tief indizieren als die kanonische Version.
- Indexierungsseite: Wenn der Inhalt mehrerer URLs sehr ähnlich ist (Duplizierungsrate über 80%), nimmt die Suchmaschine normalerweise die kanonische Version in ihren Index auf. Andere Versionen werden möglicherweise nicht separat indiziert, oder selbst wenn sie indiziert werden, nehmen sie nicht am primären Ranking-Wettbewerb teil.
- Gewichtungsseite: Wenn externe Links auf eine der doppelten URLs verweisen, verwendet die Suchmaschine die Anweisung des kanonischen Tags, um dieses externe Linkgewicht auf die kanonische Version zu “**übertragen**” oder “**zuzuordnen**” (obwohl es nicht zu 100% übertragen wird, ist der Effekt in den meisten Fällen ähnlich).
Ein realistisches Szenario: Ein Blog-Artikel wird gleichzeitig in zwei Spalten veröffentlicht: “**Startseiten-Empfehlung**” und “**Technologie-Spalte**”, was zu zwei URLs führt:
https://beispiel.de/startseite/empfehlung/123(Eingang der Startseiten-Empfehlung)https://beispiel.de/technik/artikel/123(Eingang der Technologie-Spalte)
Der Inhalt beider ist identisch, aber die URL der Startseiten-Empfehlung hat aufgrund des höheren Traffics einige externe Links angezogen.
Ohne den kanonischen Tag würde die Suchmaschine die beiden Seiten wahrscheinlich als unabhängige Inhalte behandeln. Obwohl die URL der Startseiten-Empfehlung externe Links hat, ist ihr Ranking-Potenzial möglicherweise nicht so gut wie das der Technologie-Spalte, da die Spaltenpositionierung nicht sehr vertikal ist (Startseiten-Empfehlungen sind oft allgemeine Inhalte).
Wenn das technische Team den kanonischen Tag auf beiden Seiten hinzufügt und auf https://beispiel.de/technik/artikel/123 verweist, was thematisch besser zum Inhalt passt, weiß die Suchmaschine klar: “Die autoritative Version dieses Inhalts ist die URL der Technologie-Spalte” und ordnet das externe Linkgewicht der Startseiten-Empfehlung ebenfalls zu, was die Ranking-Fähigkeit dieser Seite unter “**technologiebezogenen Keywords**” stärkt.
Was passiert, wenn der Canonical Tag nicht verwendet wird?
Das Crawl-Budget des Crawlers wird verschwendet
Die “tägliche Crawl-Anzahl”, die Suchmaschinen jeder Website zuweisen, ist begrenzt (bekannt als “Crawl-Budget”). Es wird bevorzugt, wichtige Seiten zu crawlen (z. B. Startseite, häufig aktualisierte Inhaltsseiten).
Wenn eine Website eine große Anzahl doppelter URLs hat (z. B. eine E-Commerce-Produktlistenseite mit 10 Sortierparametern, die über 1.000 verschiedene URLs generiert), verbraucht der Crawler einen Teil des Budgets für diese Seiten, die “**denselben Inhalt, aber unterschiedliche URLs**” haben, was die Crawl-Frequenz der neuen Seiten, die tatsächlich gecrawlt werden müssen (z. B. neu gelistete Produkte, aktualisierte Informationen), reduziert.
Daten zeigen: Basierend auf der Analyse von Crawl-Protokollen einer Bekleidungs-E-Commerce-Website verbrauchten doppelte Produktseiten mit Parametern (z. B. ?größe=M, ?farbe=blau) 22% des gesamten Crawl-Volumens, während die Absprungrate dieser Seiten bis zu 85% betrug (Benutzer, die nach bestimmten Artikeln suchen, gelangen nicht über parametrisierte URLs dorthin).
Nachdem diese Website den kanonischen Tag für Produktdetailseiten vereinheitlicht hatte (Weiterleitung auf die nicht parametrisierte Basis-URL), stieg die Crawl-Frequenz für die Hauptproduktseiten um 30%, und die Indexierungszeit für neu gelistete Produkte verkürzte sich von durchschnittlich 7 Tagen auf 3 Tage.
Indexversionen sind verwirrt, Ranking ist instabil
Ohne kanonische Angabe wählt die Suchmaschine möglicherweise eine beliebige URL als “**Standardanzeigeversion**” aus, aber diese Wahl ist nicht immer konstant.
Zum Beispiel sehen Benutzer bei der Suche nach bestimmten Keywords manchmal die www-Version (https://www.beispiel.de/seite), manchmal die non-www-Version (https://beispiel.de/seite) oder sogar die parametrisierte Version (https://beispiel.de/seite?von=social).
Fallstudie: Die “Kontakt”-Seite einer lokalen Dienstleistungs-Website existierte gleichzeitig in zwei Versionen: https://beispiel.de/kontakt und https://beispiel.de/kontaktiere-uns (Inhalt ist identisch). Ohne kanonische Einstellung indizierte Google beide URLs zu unterschiedlichen Zeiten, was dazu führte, dass Benutzer bei der Suche nach “**XX Stadt Reparaturservice Kontaktmöglichkeit**” manchmal die erste Version höher gerankt sahen, manchmal die zweite.
Wenn Benutzer auf die nicht-kanonische Version (z. B. kontaktiere-uns) klicken, kann dies aufgrund von Unterschieden im Seiten-Navigationsdesign (z. B. Fehlen eines Online-Termin-Buttons) zu einem Rückgang der Konversionsrate führen.
Später fügte diese Website den kanonischen Tag auf beiden Versionen hinzu und verwies auf https://beispiel.de/kontakt. Drei Monate später verbesserte sich das Ranking der Seite, und die Klickrate aus der Suche (CTR) stieg um 11%.
Externe Linkgewichtung wird verteilt
Wenn mehrere doppelte URL-Versionen von externen Websites verlinkt werden (z. B. jemand verwendet die parametrisierte URL beim erneuten Veröffentlichen von Inhalten oder erstellt neue Links beim Schieben auf eine Spaltenseite), diese externen Links aber auf unterschiedliche Adressen verweisen, kann die Suchmaschine die Gewichtung nicht automatisch konsolidieren.
Datenvergleich: Ein Artikel zur “**Strategie für die Hochschulaufnahmeprüfung**” einer Bildungs-Website wurde von 5 externen Websites neu veröffentlicht, wobei 3 auf die nicht parametrisierte Version (https://beispiel.de/ratgeber/hochschule) und 2 auf die parametrisierte Version (https://beispiel.de/ratgeber/hochschule?von=partner) verlinkten.
Ohne kanonische Einstellung ordnete die Suchmaschine diese 5 externen Links unterschiedlichen URLs zu. Nachdem diese Website den kanonischen Tag für alle Versionen hinzugefügt hatte (Weiterleitung auf die nicht parametrisierte Version), stieg der organische Suchverkehr dieser Seite innerhalb von 6 Monaten um 24%.
Grundlegende Syntax und Schreibweise des Canonical-Tags
Etwa 32% der Seiten platzieren den kanonischen Tag im <body>-Bereich (anstelle des erforderlichen <head>-Bereichs), 19% der href-Attributwerte fehlt das vollständige Protokoll (z. B. nur beispiel.de statt https://beispiel.de), und 15% der doppelten Seiten verweisen auf unterschiedliche “kanonische Versionen” (was die Suchmaschine verwirrt).
Technisch gesehen ist der kanonische Tag ein einfacher HTML-Link-Tag, aber die **Position des Tags (muss innerhalb von <head> sein), die Syntax (muss strikt dem HTML-Standard entsprechen), die Ziel-URL (muss absolut identisch mit dem tatsächlichen Inhalt sein und erreichbar sein)** sind entscheidend.
Daten zeigen: Wenn der kanonische Tag dem Standardformat entsprechend implementiert wird (d. h. oben im <head> platziert, mit vollständigem HTTPS-Protokoll und Weiterleitung auf eine eindeutige, korrekte kanonische URL), liegt die Wahrscheinlichkeit, dass die Suchmaschine ihn korrekt identifiziert und verwendet, über 95%.
Bei fehlerhaft geschriebenen Seiten wird die kanonische Absicht in etwa 60% der Fälle von der Suchmaschine nicht erkannt, wodurch das Problem des doppelten Inhalts bestehen bleibt.
Zum Beispiel vergaß eine E-Commerce-Website beim Hinzufügen des kanonischen Tags für Produktdetailseiten (z. B. die parametrisierte Version ?farbe=rot), das Protokollpräfix einzufügen (schrieb //beispiel.de/produkt oder beispiel.de/produkt), was dazu führte, dass Google die Ziel-URL nicht korrekt parsen konnte.
Standard-Syntaxstruktur
Die vollständige Syntax des kanonischen Tags besteht nur aus einer Zeile HTML-Code: <link rel=“canonical” href=“https://www.beispiel.de/vollständige_URL_der_kanonischen_seite” />
Diese Zeile besteht aus 3 Hauptteilen, die unverzichtbar und in fester Reihenfolge sind:
Tag-Typ: <link>
- Dies ist der Tag, der in HTML verwendet wird, um die Beziehung zwischen dem Dokument und einer externen Ressource zu definieren. Der kanonische Tag ist Teil der “Link-Beziehung” und muss
<link>als Grundstruktur verwenden.
Attribut: rel="canonical"
relist ein erforderliches Attribut für den<link>-Tag, das zur Beschreibung der Beziehung des aktuellen Links zum aktuellen Dokument verwendet wird. Wenn der Wert aufcanonicalgesetzt wird, informiert er die Suchmaschine klar: “Dieser Tag definiert die kanonische (autoritative) Version des aktuellen Seiteninhalts.”
Attribut: href="URL"
hrefist ein weiteres erforderliches Attribut des<link>-Tags, das zur Angabe der spezifischen Webadresse der kanonischen Version dient. Diese URL muss **vollständig und erreichbar** sein, einschließlich Protokoll (http oder https), Domain (www oder non-www), Pfad und Parametern (falls erforderlich).
Beispiele:
- Korrekte Schreibweise:
href="https://www.beispiel.de/produkte/schuhe" - Fehler 1 (fehlendes Protokoll):
href="//www.beispiel.de/produkte/schuhe"(Browser füllen dies möglicherweise automatisch aus, aber die Suchmaschine kann die Ziel-URL möglicherweise nicht korrekt parsen) - Fehler 2 (fehlende Domain):
href="/produkte/schuhe"(Relativer Pfad, die Suchmaschine weiß nicht, unter welcher Website sich die Seite befindet) - Fehler 3 (Tippfehler):
href="https://www.baispiel.de/produkte/schuhe"(Domain-Tippfehler, verweist auf eine nicht existierende Seite)
Weitere Details:
- Dieser Tag muss mit
/enden (wenn die URL selbst einen nachgestellten Schrägstrich erfordert), aber in den meisten Fällen sind moderne Suchmaschinen gegenüber dem Vorhandensein oder Fehlen nachgestellter Schrägstriche recht tolerant (solange der Standard einheitlich ist). - Der Tag muss in einer einzigen Zeile geschrieben werden (Zeilenumbrüche können bei einigen Parsern zu Fehlern führen, obwohl Suchmaschinen dies normalerweise automatisch korrigieren können).
- Der schließende Teil des Tags ist
/>(ein selbstschließendes Tag; der HTML5-Standard erlaubt das Weglassen des letzten/, aber es wird empfohlen, es beizubehalten, um die Kompatibilität zu gewährleisten).
Warum muss es sich im <head> befinden?
Das liegt daran, dass der Suchmaschinen-Crawler beim Crawlen einer Seite die Inhalte im <head>-Bereich priorisiert parst (insbesondere Metadaten, Titel, kanonische Tags und andere “Steueranweisungen”) und erst danach den eigentlichen Inhalt im <body> verarbeitet.
Wenn der kanonische Tag fälschlicherweise innerhalb des <body> platziert wird (z. B. in einen Artikelabschnitt oder den Footer-Code eingebettet), ignoriert die Suchmaschine den <link rel="canonical">-Tag innerhalb des <body> direkt.
Weitere Ergänzungen:
- Eine Seite darf nur einen kanonischen Tag haben (wenn mehrere vorhanden sind, identifiziert die Suchmaschine normalerweise nur den ersten und ignoriert den Rest).
- Dieser Tag kann nicht in andere Tags verschachtelt werden (z. B. kann er nicht in
<div>oder<script>platziert werden). - Bei dynamisch generierten Seiten (z. B. Seiten, die über Backend-Sprachen wie PHP, Python ausgegeben werden) muss sichergestellt werden, dass die Template-Engine den kanonischen Tag beim Ausgeben des HTML-Codes korrekt in den
<head>-Bereich einfügt (dies wird normalerweise über Template-Variablen gesteuert).
5 häufigste Fehler
Fehler 1: Weiterleitung auf eine fehlerhafte URL (die kanonische Version entspricht nicht der tatsächlichen Absicht)
- Phänomen: Der kanonische Tag verweist auf eine URL, deren Inhalt nicht vollständig konsistent ist (oder überhaupt nicht derselbe Inhalt ist). Zum Beispiel verweist der kanonische Tag einer Produktdetailseite (die rote Schuhe zeigt) auf eine Seite mit weißen Schuhen.
- Folge: Die Suchmaschine folgt der fehlerhaften Anweisung und konsolidiert das Gewicht auf die irrelevante Seite, was das Ranking des Hauptinhalts reduziert.
- Lösung: Überprüfen Sie den tatsächlichen Inhalt der aktuellen Seite und stellen Sie sicher, dass die URL im href auf die kanonische Version verweist, die “**exakt denselben Inhalt**” anzeigt (z. B. die einheitliche, nicht parametrisierte Basis-URL oder die Spaltenseite, die der Suchabsicht des Benutzers am besten entspricht).
Fehler 2: Fehlen des Protokollpräfixes (nur die Domain schreiben oder relative Pfade verwenden)
- Phänomen: Der Code ist als
href="//beispiel.de/seite"(protokollrelativer Pfad) oderhref="/seite"(relativer Pfad) geschrieben. - Folge: Die Suchmaschine kann die Ziel-URL möglicherweise nicht genau parsen (insbesondere in Protokoll- oder Domain-übergreifenden Szenarien), wodurch die kanonische Absicht nicht funktioniert.
- Lösung: Verwenden Sie immer das vollständige Protokoll + Domain + Pfad. Das Format lautet
href="https://www.beispiel.de/seite"(HTTPS-Protokoll wird aus Sicherheitsgründen empfohlen).
Fehler 3: Parametrisierte URLs widersprechen der kanonischen Version
- Phänomen: Die nicht parametrisierte Version einer Listenseite (
https://beispiel.de/produkte) ist die kanonische Version, aber eine parametrisierte Version (z. B.https://beispiel.de/produkte?sortieren=preis) verweist nicht korrekt darauf, sondern auf eine andere parametrisierte URL (z. B.?sortieren=datum). - Folge: Mehrere parametrisierte Versionen verweisen auf unterschiedliche URLs, was zu einer “kanonischen Schleife” oder Gewichtsverteilung führt.
- Lösung: Konsolidieren Sie den kanonischen Tag aller parametrisierten URLs, um auf die nicht parametrisierte Basis-URL (oder die am häufigsten verwendete Sortier-/Filterversion) zu verweisen und sicherzustellen, dass alle unterschiedlichen Versionen auf dieselbe kanonische Adresse verweisen.
Fehler 4: Tag innerhalb des <body> platziert
- Phänomen: Bei der Bearbeitung der Seite über das Backend-CMS wurde der kanonische Code versehentlich in den Inhaltsbereich des Artikels (den <body>-Teil) anstatt in den <head>-Bereich der Website-Vorlage eingefügt.
- Folge: Der Suchmaschinen-Crawler ignoriert diesen Tag möglicherweise, wodurch doppelte Seiten nicht korrekt kanonisiert werden.
- Lösung: Bitten Sie das technische Team, die Vorlagendateien (z. B. header.php in WordPress, theme.liquid in Shopify) zu überprüfen, um sicherzustellen, dass der kanonische Tag korrekt innerhalb des <head>-Tags des HTML ausgegeben wird.
Fehler 5: Überlagerung mehrerer kanonischer Tags
- Phänomen: Aufgrund eines Vorlagenfehlers oder einer manuellen Hinzufügung erscheinen auf einer Seite mehrere
<link rel="canonical">-Tags (z. B. verweisen sie gleichzeitig auf /seite und /seite/). - Folge: Die Suchmaschine identifiziert normalerweise nur den ersten Tag, nachfolgende Tags werden ignoriert, was zu Verwirrung über die kanonische Absicht führen kann.
- Lösung: Überprüfen Sie den Code, entfernen Sie redundante kanonische Tags und stellen Sie sicher, dass jede Seite nur eine einzige kanonische Anweisung hat.
Unterschied zwischen Canonical und anderen Tags (z. B. noindex, 301-Weiterleitung)
Der kanonische Tag dient dazu, “**die autoritative Version desselben Inhalts festzulegen**” (alle URLs beibehalten, aber Gewichtung konzentrieren), der noindex-Tag dient dazu, “**Suchmaschinen die Indexierung der aktuellen Seite zu verbieten**” (Crawling zulassen, aber nicht anzeigen), und die 301-Weiterleitung dient dazu, “**die alte URL dauerhaft auf die neue URL umzuleiten**” (Übertragung von Traffic und Gewichtung).
Wesentliche Unterschiede zwischen Kanonisierung, Blockierung, Weiterleitung
Canonical Tag (kanonischer Tag): Wird für “**Szenarien mit mehreren URLs für denselben Inhalt**” verwendet, um der Suchmaschine mitzuteilen, dass “der Inhalt dieser Seiten identisch ist, Sie sich aber nur auf diese von mir festgelegte URL (die kanonische Version) konzentrieren und das Gewicht hier konsolidieren sollen.”
- Typische Szenarien: Parametrisierte E-Commerce-Produktdetailseiten (z. B. ?farbe=rot und ?farbe=blau), Pressemitteilungen, die in mehrere Spalten geschoben werden (z. B. “Neueste Nachrichten” und “Industrietrends”), separate URLs für Mobil- und PC-Versionen mit identischem Inhalt.
Noindex Tag (Indexierungsverbot): Wird für “**Szenarien verwendet, in denen das Crawling erlaubt, aber die Anzeige verboten ist**”, um der Suchmaschine mitzuteilen, dass “Sie diese Seite crawlen dürfen, sie aber nicht in den Suchindex aufnehmen sollen.”
- Typische Szenarien: Interne Verwaltungsseiten (z. B. Anmeldeseiten, Backend-Statistikseiten), temporäre Veranstaltungsseiten (die nach Ende der Veranstaltung kein Ranking mehr benötigen), minderwertige Inhaltsseiten (z. B. Druckversionen, Seiten zur Konvertierung von traditionellen/vereinfachten Zeichen).
301 Redirect (dauerhafte Weiterleitung): Wird für “**Szenarien verwendet, in denen Inhalte dauerhaft verschoben wurden**”. Dies wird über den Server konfiguriert (z. B. .htaccess-Datei oder Nginx-Regeln), um Benutzer und Suchmaschinen automatisch von der alten URL zur neuen URL umzuleiten. Das Gewicht der alten URL (einschließlich Ranking, externe Links, Benutzervertrauen) wird schrittweise auf die neue URL übertragen, und die alte URL wird schließlich möglicherweise nicht mehr direkt aufgerufen (aber die Weiterleitung bleibt bestehen).
- Typische Szenarien: Website-Domain-Änderung (z. B. Umzug von beispiel.de nach neuesbeispiel.de), URL-Umstrukturierung (z. B. Änderung von /altes-produkt/ zu /produkte/neues-produkt/), Konsolidierung mehrerer alter Seiten zu einer einzigen neuen Seite.
| Tool | Crawling erlaubt? | Indexierung erlaubt? | URL-Wechsel? | Hauptzweck |
|---|---|---|---|---|
| Canonical | ✅ Erlaubt | ❌ Empfohlen, nicht zu indizieren (könnte aber indiziert werden) | ❌ Nein | Konsolidierung des Gewichts mehrerer identischer Inhalte auf die kanonische Version |
| Noindex | ✅ Erlaubt | ❌ Verboten | ❌ Nein | Verhindert, dass die Seite in den Suchergebnissen erscheint |
| 301 Redirect | ❌ Automatische Weiterleitung | ❌ Alte URL wird nicht indiziert | ✅ Ja, auf die neue URL | Überträgt das Gewicht und den Traffic der alten URL auf die neue Adresse |
4 typische Szenariensets zum Vergleich der Verwendung
Szenario 1: Derselbe Inhalt hat mehrere URLs (z. B. parametrisierte Produktseiten)
- Problem: Eine Produktdetailseite ist über
https://beispiel.de/produktundhttps://beispiel.de/produkt?farbe=rotzugänglich. Der Inhalt ist identisch. - Korrektes Tool: Canonical. Fügen Sie den kanonischen Tag zur parametrisierten URL (
?farbe=rot) hinzu und verweisen Sie auf die nicht parametrisierte Basis-URL (https://beispiel.de/produkt), um der Suchmaschine mitzuteilen: “Die autoritative Version dieses Inhalts ist die Seite ohne Parameter.” - Warum nicht noindex/301: noindex würde dazu führen, dass die parametrisierte Seite nicht indiziert wird (obwohl sie möglicherweise gecrawlt wird), aber Benutzer könnten über diesen Link dorthin gelangen, und die Suchmaschine muss immer noch entscheiden, welche Version die Hauptversion ist. 301 Redirect würde Benutzer und Crawler zur Umleitung zwingen, aber Benutzer benötigen möglicherweise Zugriff über verschiedene Parameter (z. B. zum Vergleichen verschiedener Farben), daher ist es nicht für eine erzwungene Weiterleitung geeignet.
Szenario 2: Eine Seite soll nicht mehr in den Suchergebnissen erscheinen (z. B. abgelaufene Veranstaltungsseite)
- Problem: Eine Aktionsseite (
https://beispiel.de/promo) ist abgelaufen, aber Benutzer könnten über Lesezeichen oder externe Links dorthin gelangen, und es soll kein Ranking mehr erhalten. - Korrektes Tool: Noindex. Fügen Sie das Tag
<meta name="robots" content="noindex">in den<head>der Aktionsseite ein (oder stellen Sie es über das CMS ein), um der Suchmaschine zu erlauben, die Seite zu crawlen (z. B. um Protokolle der Veranstaltung zu überprüfen), aber sie nicht in den Index aufzunehmen. - Warum nicht canonical/301: canonical löst nicht das Problem, “**dass die Seite nicht erscheint**” (es konzentriert nur das Gewicht). 301 Redirect erfordert die Angabe einer neuen URL (aber die Aktionsseite hat keine entsprechende neue Adresse), und Benutzer müssen möglicherweise auf die ursprüngliche Seite zugreifen, um historische Informationen anzuzeigen.
Szenario 3: Website ändert Domain oder URL-Struktur (z. B. Verschieben alter Produktseiten)
- Problem: Eine alte Produktseite (
https://alt.beispiel.de/artikel1) wurde dauerhaft an eine neue Adresse (https://neu.beispiel.de/produkte/artikel1) verschoben, und das ursprüngliche externe Linkgewicht und das Benutzerzugriffsverhalten müssen beibehalten werden. - Korrektes Tool: 301 Redirect. Konfigurieren Sie über den Server (z. B. Apache .htaccess-Datei): Wenn Benutzer oder Crawler auf die alte URL zugreifen, werden sie automatisch zur neuen URL umgeleitet. Das Ranking und das externe Linkgewicht der alten URL werden schrittweise auf die neue URL übertragen.
- Warum nicht canonical/noindex: canonical kann keinen Traffic umleiten (Benutzer bleiben auf der alten URL). noindex würde dazu führen, dass die alte URL nicht indiziert wird, aber das externe Linkgewicht wird nicht übertragen, und Benutzer können über den alten Link nicht auf den neuen Inhalt zugreifen.
Szenario 4: Separate URLs für Mobil- und PC-Versionen (z. B. m.beispiel.de und www.beispiel.de)
- Problem: Derselbe Inhalt hat separate URLs für Mobil (
https://m.beispiel.de/seite) und PC (https://www.beispiel.de/seite). Der Inhalt ist identisch. - Korrektes Tool: Bevorzugen Sie die Verwendung von canonical (Weiterleitung auf die PC-URL) oder konsolidieren Sie die URLs mit responsivem Design. Wenn die mobile Version ein notwendiger Eingang ist (z. B. Benutzer sind es gewohnt, über m.beispiel.de zuzugreifen), kann der kanonische Tag auf der mobilen Seite hinzugefügt werden, um auf die PC-kanonische URL zu verweisen, und gleichzeitig können einige alte mobile Links über 301 Redirect auf die PC-Version weitergeleitet werden (optional).
- Warum nicht noindex: noindex würde dazu führen, dass entweder die mobile oder die PC-Version nicht indiziert wird, was dazu führen könnte, dass einige Benutzer-Suchbedürfnisse nicht erfüllt werden (z. B. mobile Benutzer sehen keine angepassten Inhalte).
Wie wird der Code geschrieben? Wie unterscheidet sich die Funktionslogik?
Canonical Tag: HTML-Code, abhängig vom Parsen der Suchmaschine
- Schreibweise: Fügen Sie
<link rel="canonical" href="https://kanonische_URL" />in den<head>-Bereich der Seite ein, die kanonisiert werden soll (wie im vorherigen Kapitel beschrieben).
Funktionslogik: Wenn die Suchmaschine die Seite crawlt, liest sie diesen Tag und notiert, dass “die kanonische Version dieser Seite XXX ist”. Bei der späteren Ranking-Berechnung und Gewichtszuweisung wird die kanonische Version bevorzugt behandelt. Andere Versionen der Seite werden möglicherweise weiterhin gecrawlt (sofern keine anderen Einschränkungen bestehen).
Noindex Tag: HTML-Meta-Tag oder HTTP-Antwort-Header, abhängig von der Einhaltung der Crawler-Regeln
- Schreibweise: Normalerweise wird
<meta name="robots" content="noindex">in den<head>der Seite eingefügt (anwendbar für die meisten Szenarien) oder der HTTP-Antwort-HeaderX-Robots-Tag: noindexüber den Server gesendet (anwendbar für dynamische Seiten).
Funktionslogik: Wenn die Suchmaschine die Seite crawlt, erkennt sie diese Anweisung. Wenn bestätigt wird, dass die Seite die noindex-Bedingung erfüllt (z. B. keine Spam-Seite ist), wird sie nicht in den Index aufgenommen. Die Seite wird jedoch weiterhin gecrawlt (es sei denn, robots.txt wird zum Blockieren des Crawlings verwendet), und Benutzer können über direkte Links darauf zugreifen.
301 Redirect: Serverkonfiguration, erzwungene Traffic-Umleitung
Schreibweise: Implementierung über Servertechnologie. Zum Beispiel:
- Apache-Server: Fügen Sie
Redirect 301 /alte-seite https://beispiel.de/neue-seitein die .htaccess-Datei ein. - Nginx-Server: Fügen Sie
return 301 https://beispiel.de/neue-seite;in die Konfigurationsdatei ein. - CMS-Systeme (z. B. WordPress): Stellen Sie Umleitungsregeln über Plugins (z. B. Redirection) ein.
Funktionslogik: Wenn Benutzer oder Suchmaschinen auf die alte URL zugreifen, sendet der Server automatisch den Statuscode 301 und leitet zur neuen URL um. Die Adressleiste des Browsers zeigt die neue Adresse an. Das Ranking der alten URL wird schrittweise (normalerweise Wochen bis Monate) auf die neue URL übertragen, und die alte URL wird schließlich möglicherweise nicht mehr direkt aufgerufen (aber die Weiterleitungsfunktion bleibt erhalten).
