Indexierung, Canonicals, Weiterleitungen, Duplikate und HTTP-Statuscodes

Direkte Antwort

Indexierbarkeit entscheidet, ob eine abrufbare Seite in einen Index aufgenommen werden darf. Kanonisierung entscheidet, welche URL eine Gruppe von doppelten oder sehr ähnlichen Seiten repräsentieren darf. Ein Canonical-Tag macht eine Seite nicht indexierbar, zwingt Google nicht, sie auszuwählen, und leitet Nutzer nicht weiter.

Lege zuerst den gewünschten Zustand fest und richte dann HTTP-Antwort, Weiterleitung, Index-Direktive, Canonical, interne Links, Sitemap und hreflang danach aus. Google beschreibt Weiterleitungen und rel="canonical" als starke Canonical-Signale und die Aufnahme in die Sitemap als schwächer. Widersprüchliche Signale erzeugen Mehrdeutigkeit, und Google kann ein anderes Canonical auswählen.

Gib für entfernte Inhalte einen aussagekräftigen 404 oder 410 zurück, wenn kein Ersatz existiert. Leite nur auf einen relevanten Ersatz weiter. Eine 200-Seite, die „nicht gefunden" sagt, ist keine harmlose Design-Entscheidung. Sie kann zu einem Soft 404 werden und Diagnosezeit verschwenden.

Was du danach kannst

Am Ende dieser Lektion kannst du:

• Indexierbarkeit, Indexierung, deklariertes Canonical und ausgewähltes Canonical voneinander unterscheiden;
• vorhersagen, wie sich gängige HTTP-Zustände auf Crawling und Index-Eignung auswirken;
• zwischen permanenter Weiterleitung, temporärer Weiterleitung, Canonical, noindex, 404 und 410 wählen;
• einen Cluster doppelter URLs auflösen;
• „Google hat ein anderes Canonical gewählt" diagnostizieren, ohne widersprüchliche Direktiven hinzuzufügen;
• technische Kombinationen als ungültig, widersprüchlich, schwach oder akzeptabel einordnen.

Vier Zustände, die Teams verwechseln

Indexierbar

Die Seite hat keine bekannte technische Direktive, die die Index-Eignung verhindert. Sie kann trotzdem wegen Duplizierung, Qualität, Zugriff oder Systementscheidung ausgeschlossen sein.

Indexiert

Das Suchsystem speichert die Seite oder ihren kanonischen Vertreter aktuell.

Deklariertes Canonical

Der Website-Betreiber gibt über rel="canonical" im HTML oder einen unterstützten HTTP-Link-Header eine bevorzugte Vertreter-URL an.

Ausgewähltes Canonical

Das Suchsystem wählt anhand mehrerer Signale einen Vertreter für einen Duplikat-Cluster aus.

Eine Seite kann sich selbst als kanonisch deklarieren, während Google eine andere URL auswählt. Das Tag ist ein Signal, kein Befehl.

Warum Duplikat-Cluster entstehen

Eine Ressource kann erscheinen über:

• HTTP und HTTPS;
• www und Nicht-www;
• Tracking-Parameter;
• Filter und Sortierungen;
• Druck- oder PDF-Versionen;
• mobile Alternativen;
• Sitzungs- oder Mandanten-Parameter;
• kopierte oder übersetzte Inhalte;
• alte und neue Routenstrukturen.

Nicht jedes Duplikat ist eine Abstrafung. Kanonisierung hilft Systemen, Signale zu konsolidieren und einen Vertreter auszuwählen. Das eigentliche Problem sind unkontrolliertes Inventar, widersprüchliche Zuständigkeit, verschwendetes Crawling und die falsche angezeigte URL.

Canonical-Signale und ihre Stärke

Googles Dokumentation zur Kanonisierung beschreibt:

• Weiterleitungen als starkes Signal dafür, dass das Ziel kanonisch sein sollte;
• rel="canonical" als starkes Signal;
• die Aufnahme in die Sitemap als schwaches Signal;
• konsistente interne Links als unterstützenden Beleg.

Signale können sich stapeln. Eine permanente Weiterleitung auf URL A, ein Self-Canonical auf A, interne Links zu A und die Sitemap-Aufnahme von A kommunizieren gemeinsam einen einzigen Zustand.

Signale können auch widersprechen. Eine Seite, die per Canonical auf A verweist, während Links, Sitemap und hreflang B stützen, erzeugt vermeidbare Mehrdeutigkeit.

Wann welcher Mechanismus zum Einsatz kommt

Permanente Weiterleitung

Nutze 301 oder 308, wenn Nutzer und Crawler künftig die Ersatz-URL verwenden sollen.

Beispiele:

• HTTP zu HTTPS;
• alter Slug zu neuem Slug;
• zusammengeführte Seite zum nächstliegenden Äquivalent.

Googles Leitfaden zu Weiterleitungen behandelt serverseitige permanente Weiterleitungen als starke Canonical-Signale.

Temporäre Weiterleitung

Nutze 302, 303 oder 307, wenn die ursprüngliche URL langfristig Eigentümer bleibt und der Umzug vorübergehend ist.

Lass einen „temporären" Zustand nicht unbegrenzt bestehen, ohne zu prüfen, ob sich die vorgesehene Eigentümerschaft geändert hat.

Canonical

Nutze ein Canonical, wenn mehrere zugängliche Varianten verfügbar bleiben müssen, aber eine davon den Cluster in der Suche repräsentieren soll.

Beispiele:

• Tracking-Parameter;
• druckfreundliches HTML;
• Syndizierung oder unterstützte Produktvarianten.

Nutze Canonical nicht als Ersatz für eine geeignete Weiterleitung, wenn die Alternative nicht mehr besucht werden soll.

Noindex

Nutze noindex, wenn eine abrufbare Seite nicht in der Suche erscheinen soll. Es konsolidiert die Signale der Seite nicht auf eine andere URL, so wie es eine Weiterleitung oder ein Canonical tun kann.

Googles Anleitung zu Noindex verlangt, dass der Crawler auf die Seite zugreift und die Direktive liest.

404 oder 410

Nutze 404 Not Found oder 410 Gone, wenn weder eine Ressource noch ein relevanter Ersatz existiert. Leite eine veraltete Seite nicht nur deshalb auf eine themenfremde Startseite weiter, um einen Fehler zu vermeiden.

HTTP-Zustände und Direktiven

Googles Dokumentation zu Crawler-Statuscodes erklärt, wie seine Crawler gängige Antworten verarbeiten. Die folgende Tabelle ist eine praktische Zusammenfassung, keine Zeitgarantie.

Google folgt in der Regel bis zu zehn Weiterleitungssprüngen, aber interne Links in Produktion sollten direkt auf die finale URL zeigen. Eine Kette erzeugt Latenz, zusätzliche Fehlerquellen und Wartungsaufwand.

Soft 404s

Ein Soft 404 tritt auf, wenn die Antwort erfolgreich wirkt, der Inhalt aber vermittelt, dass die Ressource fehlt, oder zu wenig Wert bietet, um als echte Seite zu gelten.

Häufige Muster:

• 200 mit „Produkt nicht gefunden";
• leere Kategorieseite mit generischer Navigation;
• alle ausgemusterten Seiten werden auf die Startseite weitergeleitet;
• ein clientseitiger Router zeigt einen Fehler, der Server liefert aber immer 200;
• eine lokalisierte Seite enthält keine lokalisierten Inhalte.

Behebe den Zustand, nicht die Beschriftung in einem Tool. Stelle substanziellen Inhalt wieder her, gib den korrekten Abwesenheitsstatus zurück, oder leite auf eine wirklich gleichwertige Ressource weiter.

Ein Verfahren zur Canonical-Auflösung

1. Den kanonischen Eigentümer festlegen

Schreibe die exakte bevorzugte URL, Sprache, Zielgruppe, den Inhaltszustand und den Grund auf, warum sie den Cluster repräsentiert.

2. Jede Variante inventarisieren

Erfasse Weiterleitungen, Parameter, alternative Protokolle, Druckdateien, Locale-URLs, mobile Routen, Kampagnen-Links und alte Slugs.

3. Jede Antwort abrufen

Notiere:

• Start- und Endstatus;
• die Weiterleitungskette;
• Header;
• das Quell-Canonical;
• das gerenderte Canonical;
• Robots- und Index-Direktiven;
• Inhaltsähnlichkeit.

4. Link- und Sitemap-Signale abbilden

Zähle interne Links nach Ziel. Prüfe Sitemap-Aufnahme, hreflang, strukturierte Daten, Feeds und Navigation.

5. Einen vorgesehenen Zustand zuweisen

Jede URL sollte sein:

• kanonischer Eigentümer;
• zugängliches Duplikat mit Canonical;
• weitergeleitete Alternative;
• nicht indexierbares öffentliches Hilfsmittel;
• fehlend;
• privat.

6. Widersprüche beseitigen

Richte Antwort, Canonical, interne Links, Sitemap und hreflang aufeinander aus. Kombiniere nicht ein Canonical auf eine Seite mit noindex, nur um „sicherzugehen".

7. Den ausgewählten Zustand überprüfen

Nutze Stichproben aus der URL-Prüfung, Index-Reporting, Logs und Performance-Daten. Googles ausgewähltes Canonical spiegelt verarbeitete Signale wider, nicht sofort deine neueste Quelldatei.

8. Regressionen überwachen

Teste Templates, Routing-Regeln, Sitemap-Generierung und Canonical-Daten in der kontinuierlichen Integration.

Durchgerechnetes Beispiel: ein Sechs-URL-Cluster für eine Lektion

Der vorgesehene Eigentümer ist:

https://www.seoryon.com/academy/canonicals/

URL 1: HTTP-Version

http://www.seoryon.com/academy/canonicals/

Gewünschter Zustand: direkter 301 oder 308 zum HTTPS-Eigentümer. Entferne alle internen HTTP-Links und Sitemap-Referenzen.

URL 2: Kampagnen-Parameter

https://www.seoryon.com/academy/canonicals/?utm_source=email

Gewünschter Zustand: Die Seite kann zugänglich bleiben, sollte aber das saubere Canonical deklarieren und die getrackte Form niemals in der dauerhaften internen Navigation oder der Sitemap verwenden.

URL 3: druckbares PDF

https://www.seoryon.com/academy/canonicals.pdf

Die Entscheidung hängt vom Zweck ab. Wenn das PDF ein nützliches, eigenständiges druckbares Asset ist, halte es zugänglich und entscheide, ob es indexiert werden soll. Wenn die HTML-Lektion die Suche besitzen soll, nutze ein unterstütztes HTTP-Link-Canonical oder eine X-Robots-Tag-Richtlinie entsprechend dem vorgesehenen Zustand. Platziere kein widersprüchliches HTML-Markup in einem PDF.

URL 4: französische Lektion

https://www.seoryon.com/fr/academy/canoniques/

Das ist kein Duplikat, nur weil es dasselbe Thema behandelt. Wenn es eine echte französische Übersetzung ist, nutze ein eigenes Self-Canonical und reziprokes hreflang mit der englischen Version. Setze Französisch nicht per Canonical auf Englisch und behaupte dann, beide Locales seien gleichwertige Alternativen.

URL 5: eingestellter alter Slug

https://www.seoryon.com/academy/canonical-tags/

Wenn die neue Lektion der direkte Ersatz ist, nutze eine permanente Weiterleitung zum kanonischen Eigentümer. Aktualisiere alle internen Links.

URL 6: versehentlicher Soft 404

https://www.seoryon.com/academy/missing-lesson/

Der Router liefert 200 mit „Lektion nicht gefunden". Ändere die Server-Antwort auf 404, entferne die Seite aus den Sitemaps und stelle sicher, dass die Fehlerseite Nutzern weiterhin bei der Navigation hilft.

Warum das trotzdem scheitern kann

Das HTML kann perfekt sein, während eine CDN-Weiterleitungsregel mobile Nutzer auf einen anderen Host schickt. Oder der Sitemap-Generator kann Parameter-URLs wieder einführen. Kanonisierung ist eine Systemeigenschaft, kein einzelnes Tag.

Der SEOryon-Canonical-Reconciler

Lade den Reconciler für Indexierbarkeit und Canonical-Signale herunter.

Erfasse für jede URL:

• den Antwortzustand;
• den Crawl-Zugriff;
• die Index-Direktive;
• das deklarierte Canonical;
• das Ziel interner Links;
• den Sitemap-Zustand;
• den vorgesehenen Eigentümer;
• die Konfliktklasse;
• die erforderliche Aktion;
• die Verifikationsquelle.

Verwende vier Konflikt-Labels:

• Ungültig: Syntax oder Zustand können wie vorgesehen nicht funktionieren.
• Widersprüchlich: Starke Signale zeigen auf unterschiedliche Eigentümer.
• Schwach: Die Richtung ist plausibel, aber unvollständig.
• Akzeptabel: Signale und vorgesehener Zustand stimmen überein.

Fehlermuster

Canonical auf eine blockierte URL

Der Crawler kann den Zielinhalt nicht zuverlässig verarbeiten. Halte kanonische Eigentümer zugänglich.

Canonical plus Noindex ohne dokumentierten Grund

Das eine sagt, konsolidiere mit einem anderen Vertreter, während das andere diese Seite ausschließt. Wähle den tatsächlich gewünschten Zustand.

Jede entfernte Seite auf die Startseite weiterleiten

Die Startseite ist kein Ersatz für jede Ressource. Gib Abwesenheit zurück, wenn es angemessen ist.

Ketten und Schleifen

Verlinke direkt auf die finale URL und teste Routing-Regeln vor der Veröffentlichung.

Für immer belassene temporäre Weiterleitungen

Prüfe, ob der Umzug noch temporär ist. Richte den Status an der tatsächlichen Eigentümerschaft aus.

Konflikt zwischen hreflang und Canonical

Jede echte Sprachversion sollte normalerweise Self-Canonical sein und auf gleichwertige Alternativen verweisen.

Übung: acht Kombinationen diagnostizieren

Ordne jede als ungültig, widersprüchlich, schwach oder akzeptabel ein und wähle dann eine Lösung.

1. 200, Indexierung erlaubt, Self-Canonical, interne Links und Sitemap stimmen überein.
2. 200, noindex, Robots-Disallow.
3. 301 zu B, während alle internen Links weiterhin auf A zeigen.
4. 200-Parameterseite mit Canonical auf die saubere URL, saubere URL ist Self-Canonical.
5. 200-„Nicht gefunden"-Seite mit Self-Canonical und Sitemap-Aufnahme.
6. Französische Seite ist Self-Canonical, englische Seite ist Self-Canonical, reziprokes hreflang.
7. 302 wird für eine zweijährige permanente Migration verwendet.
8. 404 für eine gelöschte Seite ohne Ersatz, aus Sitemap und Links entfernt.

Lösungsschlüssel

1. Akzeptabel.
2. Widersprüchlich, weil ein Crawl-Block noindex verbergen kann. Erlaube das Crawling, bis die Direktive verarbeitet wurde, sofern kein anderer Zustand vorgesehen ist.
3. Schwach und inkonsistent. Aktualisiere die Links zu B und entferne A aus der Sitemap.
4. Akzeptabel, wenn der Inhalt gleichwertig ist und die Parameter keinen eigenen Zweck haben.
5. Ungültiger vorgesehener Zustand und Soft-404-Risiko. Stelle die Seite wieder her oder gib 404 zurück.
6. Akzeptabel für echte, gleichwertige Übersetzungen.
7. Schwach oder widersprüchlich zur permanenten Absicht. Nutze nach Validierung der Migration eine geeignete permanente Weiterleitung.
8. Akzeptabel.

Abschließende Checkliste

• Der kanonische Eigentümer ist festgelegt, bevor Tags implementiert werden.
• Jede URL-Variante hat einen vorgesehenen Zustand.
• Weiterleitungen sind direkt und zeigen auf relevante Ersatzseiten.
• Permanenter und temporärer Status entsprechen der tatsächlichen Eigentümerschaft.
• Fehlende Seiten geben 404 oder 410 zurück.
• Öffentliche Inhaltsseiten geben keine irreführenden 200-Fehler zurück.
• noindex-Seiten bleiben crawlbar, bis die Direktive verarbeitet wurde.
• Canonical-Ziele sind zugänglich und indexierungsfähig.
• Quell- und gerendertes Canonical stimmen überein.
• Interne Links zeigen auf kanonische finale URLs.
• Sitemaps enthalten ausschließlich kanonische öffentliche URLs.
• hreflang- und Canonical-Signale widersprechen sich nicht.
• Die URL-Prüfung unterscheidet zwischen deklariertem und ausgewähltem Canonical.
• Logs und Performance-Daten überwachen den resultierenden Eigentümer.
• Template- und Routing-Tests verhindern Regressionen.

Häufig gestellte Fragen

Warum hat Google ein anderes Canonical gewählt?

Google kombiniert Inhaltsähnlichkeit, Weiterleitungen, Canonical-Deklarationen, interne Links, Sitemaps, Protokollpräferenz und weitere Signale. Untersuche den gesamten Cluster, statt dasselbe Tag zu wiederholen.

Leitet ein Canonical Nutzer weiter?

Nein. Es kommuniziert unterstützenden Systemen eine bevorzugte Vertreter-URL. Nutze eine HTTP-Weiterleitung, wenn Nutzer woanders hin sollen.

Ist doppelter Inhalt eine Abstrafung?

Doppelte URLs erzeugen häufiger Cluster- und Auswahlprobleme als eine manuelle Abstrafung. Spam-Richtlinien können bei manipulativer, skalierter Duplizierung greifen, aber gewöhnliche technische Duplikate brauchen Signalkonsolidierung.

Ist 410 schneller als 404?

Beide stehen für Abwesenheit. Versprich nie eine universelle Entfernungszeit. Nutze den Status, der die Ressource wahrheitsgemäß beschreibt.

Sollte jede Seite Self-Canonical sein?

Self-Canonicals sind eine nützliche Konsistenzpraxis für kanonische, indexierbare Seiten, ersetzen aber keine korrekten Weiterleitungen, Links, Sitemaps oder Inhaltsentscheidungen.

Quellen und Methodik

Community-Recherchen zeigten, dass „Google hat ein anderes Canonical gewählt", alte URL-Strukturen, Parameter-Duplikate und Canonical-Fehler weiterhin schwer in einfacher Sprache zu erklären sind. Diese Fragen prägten das durchgerechnete Beispiel. Community-Ratschläge wurden nicht als technische Autorität verwendet.

1. Google Search Central, Doppelte URLs konsolidieren, aktualisiert am 10. Juli 2026 und geprüft am 28. Juli 2026. Offizielle Anleitung zu Canonical-Signalen.
2. Google Search Central, Indexierung mit Noindex blockieren, aktualisiert am 10. Dezember 2025 und geprüft am 28. Juli 2026. Offizielle Anforderungen an Index-Direktiven.
3. Google Search Central, Weiterleitungen und die Google-Suche, aktualisiert am 14. April 2026 und geprüft am 28. Juli 2026. Offizielle Anleitung zu permanenten und temporären Weiterleitungen.
4. Google Crawling Infrastructure, HTTP-Statuscodes, aktualisiert am 4. Februar 2026 und geprüft am 28. Juli 2026. Offizielles Antwortverhalten der Crawler. Zeitangaben bleiben ohne Garantie.

Vorheriger Schritt: Crawlbarkeit und Entdeckung
Nächster Schritt: JavaScript-SEO und agentenlesbare Schnittstellen