Alternative Seite mit richtigem kanonischen Tag: was tun?

Unter „Nicht indexiert“ sammelt der Bericht „Seitenindexierung“ alle Adressen, die Google kennt und nicht in den Index aufgenommen hat, mit einem Grund je Gruppe. Vier dieser Gründe tauchen nach jedem Relaunch auf: „Alternative Seite mit richtigem kanonischen Tag“, „Seite mit Weiterleitung“, „Soft 404“ und „Serverfehler (5xx)“. Die ersten beiden beschreiben meist genau das, was du willst. Die anderen beiden sind Fehler, und sie kosten Seiten, die eigentlich in den Index gehören.

Der Bericht ist keine Fehlerliste. Google schreibt selbst, dass ein aufgeführter Grund nicht unbedingt ein Fehler ist, und dass nicht jede Adresse indexiert sein soll, sondern nur die kanonische Fassung jeder Seite. Eine Website mit 40 Beiträgen und 300 Einträgen unter „Nicht indexiert“ kann völlig gesund sein. Die Zahl sagt nichts, die Gründe sagen alles.

Die vier Gründe, die der erste Teil behandelt, „Gefunden“, „Gecrawlt“, „Duplikat“ und noindex, stehen in Warum Google deine Seiten nicht indexiert. Hier geht es um die übrigen.

„Alternative Seite mit richtigem kanonischen Tag“#

Die Adresse trägt ein Canonical, das auf eine andere zeigt, und Google ist einverstanden. Googles eigene Erklärung nennt drei Fälle: eine AMP-Seite mit kanonischer Desktopfassung, eine mobile Fassung mit kanonischer Desktopfassung oder umgekehrt. Der Satz danach lautet: „Sie müssen nichts weiter unternehmen.“ Sprachversionen erkennt die Search Console hier ausdrücklich nicht.

In eigener Sache: Welche der Meldungen auf deiner Website ein echter Fehler ist, klärt der SEO-Check: Indexierung und Technik prüfen lassen, 390 €.

Die Meldung ist also ein Problem nur in einem Fall: Steht hier eine Seite, die selbst gefunden werden soll, zeigt ihr Canonical auf die falsche Adresse. Hat die Website weder AMP noch eine eigene Mobilfassung, lohnt der Blick auf die Beispiel-Adressen der Gruppe. Varianten mit Parametern wie ?utm_source= oder ?sort=, die auf die Hauptseite zeigen, sind in Ordnung. Leistungsseiten oder Beiträge sind es nicht. Die üblichen Ursachen:

• Ein Theme oder Plugin setzt auf jeder Seite das Canonical der Startseite. Dann landen alle Unterseiten hier.
• Das Canonical nennt eine Adresse, die weiterleitet, etwa http:// oder die Fassung ohne www. Google nennt widersprüchliche Signale ausdrücklich als Fehler.
• Nach einem Umzug zeigt das Canonical auf die alte Domain oder auf eine Testumgebung.

Was im Quelltext steht, zeigt ein Abruf, und als HTTP-Kopfzeile kann es auch gesetzt sein:

curl -s https://www.beispiel.at/leistungen/ | grep -io '<link[^>]*rel="canonical"[^>]*>'
curl -sI https://www.beispiel.at/leistungen/ | grep -i '^link:'

Das Canonical ist für Google ein Hinweis, keine Anweisung. Eine 301 ist das stärkere Signal, die Sitemap ein schwaches. Was Google am Ende gewählt hat, steht in der URL-Prüfung unter „Von Google ausgewählte kanonische URL“, gleich neben der Zeile, die du selbst angegeben hast. Wie man beide liest, steht in Die URL-Prüfung der Search Console lesen.

Wie weit Googles Wahl danebenliegen kann, zeigt ein Fall aus meiner eigenen Messung vom 03.10.2026. Bei 187 der 207 abgefragten Adressen von cyberscale.io gab es beide Zeilen, mein Canonical und das von Google. 186 Mal meinten sie dieselbe Seite, einmal davon nur ohne den Schrägstrich am Ende. Bei einer alten DSGVO-Seite nannte Google als kanonische Fassung eine PDF-Datei auf einer fremden Domain, abgelegt im Upload-Ordner eines Kontaktformulars. Die Seite gibt es seit dem 04.10. nicht mehr. Das war der Status „Duplikat“, nicht „Alternative Seite“, aber dieselbe Zeile der URL-Prüfung hat es gezeigt.

„Seite mit Weiterleitung“#

Die Adresse leitet auf eine andere weiter und wird deshalb nicht indexiert. Ob das Ziel in den Index kommt, entscheidet Google getrennt. Nach einem Relaunch ist das der richtige Platz für jede alte Adresse, und auch http:// und die Fassung ohne www gehören hierher. Zu tun ist nichts.

Prüfen solltest du drei Dinge:

1. Steht eine weitergeleitete Adresse in der Sitemap? Die Sitemap soll nur Endadressen nennen. Ein Eintrag hier, der aus der eingereichten Sitemap stammt, ist ein Fehler in der Sitemap.
2. Verweisen eigene Seiten auf die alte Adresse? Jeder interne Verweis auf eine Weiterleitung ist ein Umweg. Interne Verweise gehören auf das Ziel.
3. Endet die Weiterleitung beim richtigen Ziel, in einem Schritt? Google folgt bis zu zehn Weiterleitungen, danach meldet die Search Console einen „Weiterleitungsfehler“. Ein Ziel, das die alte Frage nicht beantwortet, kann Google als Soft 404 werten. Wann eine 410 die bessere Antwort ist, steht in 410 Gone statt 301.

Eine Eigenheit der URL-Prüfung führt hier oft in die Irre: Für eine weitergeleitete Adresse zeigt sie den Indexstand dieser Adresse, die Weiterleitung ignoriert sie. Erst der Live-Test folgt ihr.

Was „nicht indexiert“ bei 184 eigenen Adressen bedeutete#

In eigener Sache: Am Morgen des 03.10.2026 habe ich 207 Adressen von cyberscale.io (bis zum 10.10.2026 die Adresse dieser Website, seither www.cyberscale.dev) über die URL-Inspection-API abgefragt, die Adressen der Sitemap und alle alten, die Google noch kannte. 184 davon standen als „Gecrawlt – zurzeit nicht indexiert“. Danebengelegt habe ich, was jede Adresse an diesem Tag tatsächlich lieferte:

• 118 leiteten an diesem Tag per 301 weiter. Keine stand in der Sitemap. Den letzten Abruf durch Google hatten alle zwischen dem 13.08. und dem 13.09.2026, also vor dem 14.09., an dem die ersten Weiterleitungen live gingen. Google hatte sie seitdem kein einziges Mal besucht.
• 30 lieferten 200 mit noindex. Gelesen hatte Google es bei keiner, sonst stünden sie unter „Durch ‚noindex‘-Tag ausgeschlossen“. Der letzte Abruf lag zwischen dem 06.09. und dem 30.09.2026.
• 36 waren aufnahmefähige Seiten aus der Sitemap, 33 davon im Oktober abgerufen. Nur bei ihnen ist die Meldung das, was sie zu sein behauptet: ein Urteil über die aktuelle Seite.

Die 118 hätten in der Search Console als „Seite mit Weiterleitung“ stehen müssen und standen dort nicht, weil der Bericht den Zustand beim letzten Abruf zeigt, nicht den von heute. Zwei Tage später, am 05.10.2026, habe ich jede dritte noch bestehende Weiterleitung erneut abgefragt: 25 Adressen, 21 weiter als „Gecrawlt“, 4 unbekannt, keine seit ihrer Weiterleitung abgerufen. Wer nach einem Umbau den Bericht liest, ohne auf das Datum des letzten Crawls zu achten, bewertet eine Website, die es nicht mehr gibt.

„Soft 404“#

Der Server antwortet mit 200, die Seite sieht für Google aber wie eine Fehlerseite aus: „Nicht gefunden“ als Text, kaum Inhalt, eine leere Liste. Google empfiehlt, für echte „Nicht gefunden“-Seiten einen 404 zu liefern und Seiten, die keine Fehler sind, so zu füllen, dass sie nicht wie einer aussehen. Bei WordPress-Seiten sind die üblichen Kandidaten:

• leere Kategorie- und Schlagwortarchive,
• die interne Suche ohne Treffer, wenn sie indexierbar ist,
• Produkte mit „nicht mehr lieferbar“ und sonst nichts,
• eine eigene Fehlerseite aus einem Plugin, die mit Status 200 ausgeliefert wird.

Die letzte findest du in einer Sekunde:

curl -s -o /dev/null -w "%{http_code}\n" https://www.beispiel.at/gibt-es-sicher-nicht-123/

Die Antwort muss 404 sein. Bei cyberscale.io ist sie es, geprüft am 05.10.2026. Wie Google die Seite sieht, zeigt der Live-Test der URL-Prüfung unter „Getestete Seite anzeigen“ mit einem Bildschirmfoto. Ein häufiger Fall dort: Inhalte, die per JavaScript nachgeladen werden und beim Abruf durch Google nicht ankommen.

Die Lösung hängt an der Frage, ob es die Seite geben soll. Wenn nicht, 404 oder 410. Wenn sie umgezogen ist, 301 auf den Nachfolger. Wenn sie bleiben soll, Inhalt, der die Suchanfrage beantwortet, oder ein noindex, falls sie nur für Besucher da ist.

„Serverfehler (5xx)“#

Der Server hat beim Abruf mit einem Fehler der Gruppe 5xx geantwortet. Google verlangsamt dann vorübergehend das Crawling, und Adressen, die dauerhaft mit einem Serverfehler antworten, nimmt Google aus dem Index. Das ist die einzige der vier Meldungen, die indexierte Seiten aktiv kostet.

Wo es hakt, zeigt der Bericht „Crawling-Statistik“ unter „Einstellungen“: Antworten nach Statuscode, Hoststatus, Abrufe je Tag. Die üblichen Ursachen bei kleinen Websites:

• ein überlastetes Hosting-Paket, das bei gleichzeitigen Abrufen ausfällt,
• ein PHP-Fehler nach einem Update, bei WordPress der „kritische Fehler“ mit Status 500,
• ein Wartungsmodus mit 503, der nach dem Update stehen geblieben ist. Für ein paar Minuten ist 503 richtig, über Tage nicht, wie in WordPress-Wartungsmodus beschrieben,
• eine Firewall oder ein Bot-Schutz, der den Googlebot mit 5xx statt mit der Seite beantwortet.

Ob Google jetzt durchkommt, zeigt der Live-Test der URL-Prüfung. Ein Seitenaufruf im eigenen Browser beweist nichts, weil Google von anderen Adressen und mit anderer Kennung kommt.

Crawl-Budget ist hier selten der Grund#

Wer viele Meldungen sieht, liest bald vom Crawl-Budget. Googles Leitfaden dazu richtet sich an große Websites mit mehr als einer Million Seiten, die sich wöchentlich ändern, und an mittelgroße mit mehr als 10.000 Seiten und täglichen Änderungen. Für alle anderen schreibt Google: Wenn deine Seiten anscheinend noch am Tag der Veröffentlichung gecrawlt werden, brauchst du das Handbuch nicht. Eine Firmenwebsite mit 50 Seiten hat ein Vertrauensproblem oder einen technischen Fehler, kein Budgetproblem.

Was nicht hilft#

„Fehlerbehebung überprüfen“ bei „Alternative Seite“ oder „Seite mit Weiterleitung“. Da ist nichts zu beheben. Nach einer echten Korrektur, etwa bei Soft 404 oder 5xx, ist der Knopf richtig. Die Überprüfung dauert laut Google in der Regel etwa zwei Wochen, manchmal länger, und man klickt ihn erst wieder, wenn sie abgeschlossen ist.

Weitergeleitete Adressen in der robots.txt sperren, damit der Bericht kürzer wird. Google sieht die Weiterleitung dann nie.

Die alte Adresse per „Indexierung beantragen“ einreichen, damit Google die Weiterleitung schneller sieht. Das Kontingent ist klein, und das Ziel ist die Adresse, um die es geht, nicht die alte.

Den Bericht nach einem Umbau sofort lesen und reagieren. Er zeigt den Stand beim letzten Abruf. Bei einer Domain, die Google selten besucht, ist das Wochen her.

Die Reihenfolge#

1. Je Meldung zwei, drei Beispiele in der URL-Prüfung öffnen und zuerst das Datum des letzten Crawls lesen. Liegt es vor deiner Änderung, ist die Meldung veraltet.
2. Soft 404 und Serverfehler zuerst. Sie betreffen Seiten, die in den Index sollen.
3. Bei „Alternative Seite“ die Canonicals der Beispiele prüfen, bei „Seite mit Weiterleitung“ Sitemap, interne Verweise und Ziele.
4. Nach einer echten Korrektur „Fehlerbehebung überprüfen“ und zwei Wochen warten.

Wie du die Search Console von Anfang an so einrichtest, dass du diese Fragen über die API beantworten kannst, steht in Google Search Console einrichten. Wenn du das lieber abgibst: Der SEO-Check prüft genau diese Meldungen gegen das, was der Server tatsächlich liefert.

Stand 13.10.2026. Quellen am 05.10.2026 abgerufen, eigene Adressen am 03.10. und 05.10.2026 über die URL-Inspection-API gemessen.