Warum indexiert Google meine React-Seite nicht?

Die Seite für den Crawler ist nicht Ihre Seite

Öffnen Sie Ihre Live-Seite und wählen Sie Seitenquelltext anzeigen, nicht Untersuchen. Untersuchen zeigt das DOM, nachdem Ihr JavaScript gelaufen ist; der Quelltext zeigt die Bytes, die der Server wirklich gesendet hat. Bei einer clientseitig gerenderten React-App sind das meist ein Titel, ein paar Link-Tags, ein leeres Container-Element und ein Skript-Bundle. Dieses Dokument liest ein Crawler zuerst, und bei einer jungen Seite kann es eine ganze Weile die einzige Fassung sein, die überhaupt gelesen wird.

Google sagt offen, dass es JavaScript in getrennten Phasen behandelt: Es crawlt die URL, stellt die Seite zum Rendern in eine Warteschlange und indexiert, was zurückkommt — und das Rendern wird aufgeschoben statt sofort erledigt. Daraus folgen zwei Dinge. Das erste ist offensichtlich: Inhalt, der erst nach dem Bundle existiert, wird spät indexiert, wenn überhaupt. Das zweite richtet mehr Schaden an, weil es sich nie von selbst auflöst. Einige Signale werden ausschließlich aus dieser ersten Antwort gelesen, und kein späteres Rendern rettet sie.

Das Canonical-Tag ist der klarste Fall. Googles eigene Vorgabe lautet, dass das kanonische Link-Element in den Kopfbereich des Dokuments gehört, und für die hreflang-Angaben, die Sprachvarianten verbinden, gilt dasselbe. Ein Tag, das Ihr Framework später einfügt — in den Body oder nachdem der Kopfbereich bereits ausgeliefert wurde — ist ein Tag, das zum Zeitpunkt der Entscheidung nicht da war. Im Browser sieht die Seite korrekt aus, weil der Browser es trotzdem anwendet. Es kommt nur zu spät für den einen Leser, dessen Meinung Sie ändern wollten.

Herausfinden, was Google wirklich bekommen hat

Das dauert etwa zwanzig Minuten und klärt die Frage, bevor Sie irgendetwas umschreiben. Machen Sie es gegen die Live-URL, nicht gegen eine Vorschau.

1. Lesen Sie die rohe Antwort. Holen Sie die Seite mit curl oder nutzen Sie den Quelltext. Stellen Sie zwei Fragen an das, was zurückkommt: Steht der Text, für den Sie ranken wollen, wirklich darin? Und sitzt das Canonical-Tag im head-Element statt weiter unten im Dokument? Ist eine der Antworten nein, haben Sie das Problem gefunden.
2. Lesen Sie in der Search Console die gecrawlte Seite, nicht den Livetest. Die URL-Prüfung zeigt beides. Der Livetest ist ein frischer Abruf in diesem Moment; das gecrawlte HTML ist das, was beim letzten Mal tatsächlich gespeichert wurde. Wenn beide auseinandergehen, glauben Sie der gecrawlten Fassung — dieser Unterschied ist bereits der Befund.
3. Rufen Sie eine Unterseite direkt auf. Clientseitige Router erzeugen manchmal Pfade, die der Server gar nicht ausliefert. Öffnen Sie eine Ihrer Unterseiten in einem leeren Tab oder holen Sie sie mit curl und prüfen Sie, dass sie den eigenen Inhalt zurückgibt, statt auf die Startseite umzuleiten oder eine Seite zu liefern, die nichts gefunden meldet und trotzdem Erfolg signalisiert.
4. Prüfen Sie, dass Sie einen Host ausliefern und nicht drei. Rufen Sie die Form mit www, die ohne www und die unverschlüsselte Form Ihrer Domain auf. Zwei von dreien sollten auf die dritte umleiten. Liefert mehr als eine die komplette Seite aus, haben Sie dieselbe Seite unter zwei Adressen veröffentlicht und Google die Wahl überlassen.

Der Fehler, der sich vor unseren eigenen Tests versteckte

Wir veröffentlichen AgentCeres — den AI Growth Officer unter agentceres.com — auf einem React-Framework und haben durch eine Variante dieses Problems Monate an Indexierung verloren, während jede Prüfung, die wir liefen, alles für gesund erklärte. Die Geschichte lohnt sich ganz, denn jeder Teil scheiterte auf eine Weise, die nach Erfolg aussah.

Die Search Console meldete einen großen Block unserer Seiten als Duplikate ohne vom Nutzer ausgewähltes Canonical — sie hatte also kein Canonical gefunden, dem sie traute, und selbst eines gewählt. Das Tag war vorhanden. Es lag rund vierzig Kilobyte tief in der Antwort, weil das Framework Metadaten bei jeder dynamisch gerenderten Seite streamt, während das head-Element schon etwa anderthalb Kilobyte nach dem Anfang geschlossen war. Jeder Browser wendete es an. Nur der erste Crawl-Durchgang sah es nie.

Dass diese Seiten überhaupt dynamisch waren, lag am zweiten Fehler. Ein Dutzend Routen, die wir für zur Build-Zeit vorgerendert hielten, waren es klammheimlich nicht mehr: Eine gemeinsam genutzte Header-Komponente rief einen Übersetzungs-Helfer auf, der Request-Header liest, und das Lesen eines Request-Headers genügt, um eine Seite dynamisch zu machen. Die Routentabelle des Builds druckte sie weiterhin als statisch. Das Verzeichnis der erzeugten HTML-Dateien enthielt keine davon. Zusammenfassung und Artefakt widersprachen sich, und wir hatten die Zusammenfassung gelesen.

Der dritte Teil ist der, den man mitnehmen sollte. Frameworks, die Metadaten streamen, führen meist eine Liste von Crawlern, die das alte blockierende Verhalten bekommen, und unseres brachte so eine Liste als Voreinstellung mit. Googlebot stand nicht darauf. Googles eigenes Prüfwerkzeug — der Crawler hinter dem Livetest-Knopf — schon. Der Knopf, den wir zur Kontrolle unserer Arbeit drückten, holte sich also jedes Mal die gute Fassung, während normale Crawls weiter die kaputte bekamen. Wenn Ihr Prüfwerkzeug im eigenen Stack ein Sonderfall ist, prüft es nichts.

Zwei billige Fußnoten. Unser www-Host lieferte die komplette Seite ohne Weiterleitung aus, weshalb Google sie als zweite Kopie indexiert und die Adresse aus unserer Sitemap zurückgestuft hatte; zwei Zeilen Middleware haben das erledigt. Und falls Sie zur Einstellung pro Crawler greifen wollen: Ein CDN vor Ihrem Origin cacht üblicherweise ohne Rücksicht darauf, wer gefragt hat. Welche Variante im Cache landet, bekommt der nächste Crawler. Hinter einem CDN ist eine Regel, die einen Crawler besonders behandelt, keine Regel, auf die Sie sich stützen können.

Was Sie ändern sollten, in der Reihenfolge, die sich lohnt

• Rendern Sie die Seiten vor, die gefunden werden sollen. Marketingseiten, Dokumentation, alles, wonach ein Fremder suchen könnte: Erzeugen Sie das HTML beim Build. Statische Ausgabe umgeht das ganze Problem, weil der erste Durchgang bereits Inhalt und Tags enthält.
• Rendern Sie serverseitig, was wirklich dynamisch sein muss. Auch eine Seite, die von der Anfrage abhängt, kann vollständiges HTML zurückgeben. Entscheidend ist, dass die erste Antwort vollständig ist, nicht dass sie vorab berechnet wurde.
• Halten Sie Titel, Description, Canonical und Sprach-Tags im Kopfbereich dieser ersten Antwort. Wenn Ihr Framework sie aufschieben kann, suchen Sie die Einstellung, die das unterbindet, und prüfen Sie die Korrektur am rohen HTML statt am gerenderten DOM. Das ist der Schritt, den viele für erledigt halten.
• Geben Sie jeder Seite eine echte URL und einen echten Link darauf. Routen hinter einem Fragment oder einem Klick-Handler sind nicht crawlbar. Crawler folgen Anker-Elementen mit href, eine aus Buttons gebaute Navigation ist also eine Navigation, die Google nicht ablaufen kann.
• Wählen Sie einen Host und leiten Sie die anderen weiter. Reichen Sie danach eine Sitemap ein, die nur die gewählte Form listet, damit Ihre eigenen Angaben einander nicht widersprechen.

Nichts davon ist eine Ranking-Strategie. Es ist die Voraussetzung dafür, und es lohnt sich, das an einem Nachmittag zu erledigen, gerade damit Sie nie wieder daran denken müssen. Sobald Ihre Seiten wirklich gelesen werden, entscheiden andere Fragen über den Ertrag: warum eine völlig ordentliche Seite trotzdem keinen Traffic bekommt und woher die ersten Besucher tatsächlich kommen. Und wenn Sie diese Pipeline gar nicht selbst betreiben möchten: Ein Static-Site-Generator mit einem Git-basierten Editor umgeht die Rendering-Frage schon durch seinen Aufbau, weil das, was er ausliefert, bereits fertiges HTML ist.