Was ist eine Canonical-URL, und wann verwendet man eine

Was rel=canonical wirklich tut

Derselbe Inhalt ist meist unter mehr als einer URL erreichbar. Tracking-Parameter, Sitzungs-IDs, ein abschließender Schrägstrich, http neben https, www neben der bloßen Domain, eine Druckansicht, eine sortierte Liste: Jede davon ist eine eigene URL, die denselben Text ausliefert. Sich selbst überlassen, wählt eine Suchmaschine selbst eine davon, und das muss nicht die sein, die Sie wählen würden.

Ein Canonical ist, wie Sie diese Wahl explizit treffen:

<link rel="canonical" href="https://example.com/shoes">
Link: <https://example.com/shoes>; rel="canonical"

Zwei Eigenschaften lohnt es sich zu verinnerlichen. Erstens: Es ist ein Hinweis, keine Anweisung. Google wägt ihn gegen Weiterleitungen, interne Links, Sitemap-Einträge und den Inhalt selbst ab, und es kann durchaus einen anderen Canonical wählen als den von Ihnen deklarierten. Zweitens: Es konsolidiert, statt zu löschen. Signale vom Duplikat fließen dem Canonical zu, das ist der Unterschied zu noindex, wo das Duplikat für die Suche schlicht aufhört zu existieren.

Selbstreferenzierende Canonicals

Jede indexierbare Seite sollte sich selbst als ihren eigenen Canonical deklarieren. Das klingt redundant und ist die nützlichste der drei Zeilen, denn genau das neutralisiert Parameter, mit denen Sie nicht gerechnet haben. Wenn /shoes?utm_source=newsletter https://example.com/shoes deklariert, fließt die Kampagnen-URL automatisch in die saubere ein, statt mit ihr zu konkurrieren.

Drei Regeln, um es richtig zu machen: absolute URLs einschließlich Schema verwenden, genau ein Canonical-Element pro Seite ausgeben (bei einer Seite mit zwei widersprüchlichen Canonicals werden beide ignoriert), und den Canonical im Einklang mit Ihren übrigen Signalen halten. Ein Canonical, der auf eine URL zeigt, die anderswohin weiterleitet, oder die 404 liefert, oder die ein noindex trägt, sendet widersprüchliche Anweisungen und wird abgewertet.

Domainübergreifende Canonicals

Ein Canonical kann auf eine andere Domain zeigen. Das ist der richtige Mechanismus, wenn Sie einen Artikel an eine Partnerseite oder einen Nachrichtenaggregator syndizieren: Die Kopie auf deren Domain deklariert Ihre URL als Canonical, sodass die Suchrankings Ihrem Original zufließen statt deren Zweitveröffentlichung.

Genau das macht Canonicals auch gefährlich. Nichts hindert eine Seite daran, eine URL auf einem Host zu benennen, zu dem sie keinerlei Beziehung hat, und an der Syntax sieht man einem versehentlichen domainübergreifenden Canonical nichts Falsches an. Daher rührt der Staging-Fehler.

Der Staging-Canonical-Fehler

Die meisten Frameworks und Content-Management-Systeme bauen den Canonical, indem sie eine konfigurierte Basis-URL mit dem aktuellen Pfad verketten. Diese Basis-URL steckt in einer Umgebungsvariable, einer Datenbank-Options-Zeile oder einer Konfigurationsdatei, und sie ist in jeder Umgebung anders. Erreicht der Staging-Wert die Produktion, deklariert jede Seite der Live-Website, dass die echte Version unter https://staging.example.com/... lebt.

Was folgt, geschieht still und langsam. Die Live-Seiten liefern weiterhin 200 und weiterhin den richtigen Inhalt aus. Aber jede von ihnen sagt Google, dass die maßgebliche Kopie woanders liegt, und dieses Woanders ist entweder nicht erreichbar, passwortgeschützt oder mit noindex versehen. Seiten fallen mit jedem erneuten Crawl nach und nach aus den Ergebnissen, und weil es keinen Fehler gibt, der einen Alarm auslöst, ist das erste Signal meist eine Traffic-Grafik eine Woche später. Die Reparatur wird unter Beheben eines Canonicals, der auf Staging zeigt behandelt.

Canonical, Weiterleitung oder noindex

Die drei werden oft synonym verwendet und sind es nicht:

• 301-Weiterleitung wenn das Duplikat überhaupt nicht erreichbar sein soll. Das stärkste verfügbare Signal, und die richtige Antwort für eine abgeschaltete URL oder einen Domainumzug.
• rel=canonical wenn beide URLs erreichbar bleiben müssen, aber nur eine ranken soll. Parameter, Druckansichten, syndizierte Kopien, gefilterte Listen.
• noindex wenn die Seite erreichbar bleiben muss und nicht ranken darf, und es keine gleichwertige Seite gibt, in die konsolidiert werden könnte. Interne Suchergebnisse, Dankeseiten, Kontobereiche.

Stapeln Sie sie nicht. Ein Canonical auf einer mit noindex versehenen Seite ist widersprüchlich, denn Sie verlangen gleichzeitig eine Konsolidierung in eine Seite und dass genau diese Beziehung ignoriert wird.

Verifizieren Sie, was Sie tatsächlich ausliefern

Das Template zu lesen ist keine Verifikation, denn Edge Worker, Plugins und serverseitige Logik fügen allesamt Canonicals ein, die in Ihrem Repository nie auftauchen. Lesen Sie stattdessen die Antwort: curl -s https://example.com/ | grep -i 'rel="canonical"'. Für eine einzelne Seite löst der kostenlose Canonical-Check das Tag auf und sagt, ob es auf die Seite selbst, eine andere URL auf demselben Host, die http-Version oder einen anderen Host zeigt. Um die ganze Website zu prüfen, meldet das kostenlose Website-Crawl-Tool einen Canonical-Status pro URL und markiert die Seiten, wo er fehlt, und die Seiten, wo er auf etwas anderes zeigt. Ihre wichtigsten Seiten auf den Tag zu beobachten, an dem sich der Wert ändert, ist die Aufgabe der Indexability-Option eines HostTracker-HTTP-Monitors - siehe SEO-Monitoring.