Technisches SEO für Next.js

Technisches SEO in einer Next.js-Anwendung ist kein Plugin. Es ist eine Eigenschaft davon, wie die Anwendung rendert, und es scheitert auf eine Weise, die im Browser unsichtbar bleibt: ein Canonical-Tag, das auf die falsche Sprachversion zeigt, ein hreflang-Cluster, das Übersetzungen bewirbt, die es nicht gibt, eine Sitemap, die aus einer anderen Routenliste erzeugt wurde als der, die der Router tatsächlich ausliefert.

Nichts davon zeigt sich auf einer Seite, die korrekt aussieht, wenn man sie öffnet. Es zeigt sich Monate später - als zwei URLs, die sich das Ranking einer Seite teilen, oder als Sprachversion, die nie indexiert wurde.

Was wir prüfen

• Crawl und Render. Was der Crawler im initialen HTML erhält gegenüber dem, was erst nach der Hydration erscheint - und welche Ihrer Inhalte nur im zweiten Fall existieren.
• Kanonisierung. Trailing Slashes, Umgang mit Query-Parametern, Pagination und ob jede Route sich über ihre eigene Adresse einig ist.
• Internationales Routing. Der vollständige hreflang-Cluster inklusive x-default, validiert gegen die tatsächlich vorhandenen Übersetzungen und nicht gegen die geplanten.
• Strukturierte Daten. Ein zusammenhängender @graph mit stabilen @id-Referenzen statt vier unverbundener Blöcke, die jeweils die Organisation neu deklarieren.
• Sitemaps und robots. Erzeugt aus derselben Routenquelle, aus der die Anwendung rendert, damit beide nicht auseinanderlaufen können.

Die fünf Fehler, die wir am häufigsten finden

Ein Canonical, das nie geschrieben wurde. generateMetadata ist optional, also erbt eine Route ohne diese Funktion nichts - und Google wählt eine Adresse für Sie aus, oft die mit einem Tracking-Parameter daran.

Zwei URLs, die beide antworten. /about und /about/, oder eine Sprachversion, die sowohl unter /de/about als auch unter /about ausgeliefert wird. Beide geben 200 zurück, beide werden indexiert, und die Autorität der Seite wird zwischen ihnen aufgeteilt. Die Lösung ist eine Weiterleitung, kein Canonical, und dieser Unterschied ist entscheidend.

hreflang, das eine Übersetzung bewirbt, die niemand geschrieben hat. Eine Locale-Liste in einer Konfigurationsdatei erzeugt die Alternates, also beansprucht jede Seite vier Sprachen, während es nur zwei gibt. Google folgt dem Tag, findet die falsche Sprache oder einen 404 und wertet den Cluster ab. Die Regeln im Detail.

Eine Sitemap aus einer zweiten Routenliste. Von Hand gepflegt oder aus einem Verzeichnisscan erzeugt, der Route Groups nicht kennt. Sie läuft innerhalb eines Sprints auseinander und meldet danach still und leise jedes Datum falsch.

Strukturierte Daten, die nichts beschreiben. Vier separate JSON-LD-Blöcke, jeder mit eigener Organization, keiner mit einem Bezug zum anderen. Valides JSON, kein Graph, und nichts, was eine Suchmaschine zu einer Entität auflösen könnte. Wie ein zusammenhängender Graph aussieht.

Wie wir es beheben

Indem wir es unmöglich machen, es falsch zu machen. Canonicals, Alternates und strukturierte Daten werden von einem einzigen typisierten Helper erzeugt, den jede Route aufrufen muss. Eine Seite kann nicht ohne Canonical ausgeliefert werden, weil die Metadatenfunktion ohne ihn nicht kompiliert.

Das ist die ganze Methode, und sie gehört ausgesprochen, weil sie das Gegenteil davon ist, wie technisches SEO üblicherweise geliefert wird. Ein Befunddokument mit vierzig Punkten führt zu vierzig Korrekturen - und dann geht die einundvierzigste Seite ohne Canonical live, weil die Liste eine Momentaufnahme war und niemand sie erneut erstellt hat. Ein erzeugtes Canonical lässt sich auf der nächsten Seite nicht weglassen, weil es keinen Codepfad gibt, der eine Seite ohne eines hervorbringt.

Dasselbe gilt für Sitemap und Feed: beide werden aus der Routenquelle abgeleitet, aus der die Anwendung rendert, also erscheint eine neue Seite darin, weil es sie gibt - nicht weil jemand daran gedacht hat. Und hreflang wird aus den tatsächlich vorhandenen Übersetzungen erzeugt, sodass das Löschen einer Übersetzung ihr Tag beim nächsten Build entfernt, statt eine Behauptung zurückzulassen.

Wo Erzeugung nicht möglich ist, wandert die Prüfung stattdessen in die CI. Diese Website ruft bei jedem Push jede URL ihrer eigenen Sitemap ab und lässt den Build scheitern bei einem fehlenden, doppelten oder abweichenden Canonical, bei einer Seite, die in ihrem eigenen hreflang-Cluster fehlt, und bei einer doppelten URL-Form, die antwortet statt weiterzuleiten. Die Begründung dieser Prüfung.

Diese Website ist genau so gebaut, und die Umsetzung ist öffentlich - der buildMetadata-Helper und der JSON-LD-Graph in diesem Repository sind dasselbe Muster, das wir für Kunden ausrollen.

Mehrsprachig, wo es meistens bricht

Eine einsprachige Website hat einen Weg, Kanonisierung falsch zu machen. Eine viersprachige hat das Locale-Präfix, die Standardsprache ohne Präfix, das x-default-Ziel, die Übersetzung, die in zwei Sprachen existiert und in vier behauptet wird, und einen Sprachumschalter aus einem <select>, dem ein Crawler zu keiner davon folgen kann.

Wir behandeln Locale-Liste, Präfix-Regel und Übersetzungsinventar als eine Quelle, aus der Metadaten, Sitemap und Umschalter gemeinsam lesen. Die Architektur, die daraus entsteht, ist der Unterschied zwischen einer Website mit vier Sprachversionen und einer Website mit einer Sprachversion und drei Waisen.

Was wir nicht tun

Keine Content-Strategie, keine Keyword-Recherche, keinen Linkaufbau. Das hier ist der technische Boden, auf dem diese Dinge stehen, und ein Team, das Ihnen alle vier gleichzeitig verkauft, ist meist in einem davon stark.

Wir sagen Ihnen auch, wenn die technische Arbeit nicht Ihr Engpass ist. Wenn Ihre Seiten korrekt indexiert sind, sauber auflösen und validieren und der Traffic trotzdem ausbleibt, liegt die Antwort im Content - und wir sagen das, statt ein zweites Audit zu berechnen.

Wie ein Projekt abläuft

Zuerst eine feste Bestandsaufnahme - Crawl, Render-Vergleich, Canonical- und hreflang-Validierung über jedes Routen-Template, Validierung der strukturierten Daten und Logfile-Analyse, wo Serverlogs verfügbar sind. Daraus entsteht ein nach Wirkung priorisiertes Befunddokument, in dem jeder Punkt auf den Code zurückgeführt ist, der ihn verursacht.

Dann die Korrekturen, als Pull Requests in Ihrem Repository, in dieser Reihenfolge. Danach die Prüfungen, die sie halten: Erzeugung, wo der Fehler ein fehlender Wert war, CI-Assertions, wo Erzeugung nicht möglich ist.

Wenn Sie nur den ersten Teil wollen, steht das Befunddokument für sich, und mehrere Kunden haben es selbst umgesetzt. Das ist ein vernünftiges Ergebnis, und das Audit ist das passende Format dafür.

Das messbare Ergebnis

Korrekte Indexierung der Routen, die Sie indexiert haben wollen - und sonst nichts. Rich Results, wo das Schema sie trägt. Ein hreflang-Cluster, den die Search Console ohne Warnungen validiert. Das sind keine Growth Hacks; das ist der Boden, auf dem eine Content-Strategie steht.

Was Sie erhalten

Die Befunde, geordnet nach dem, was sie Sie kosten, die Korrekturen als Pull Requests und die Prüfungen, die sie nicht zurückkommen lassen. Canonical und Sitemap aus einer Quelle abgeleitet, hreflang aus den Dateien statt aus einer Liste, und ein Crawl in der CI, der an einem verlinkten 404 scheitert.

Dazu das Vorher und Nachher: indexierte Seiten, die von der Search Console abgelehnten samt genanntem Grund, und was sich geändert hat, nachdem die Korrektur Zeit hatte, neu gecrawlt zu werden. Diese letzte Zahl kommt Wochen nach der Arbeit, und wir schicken sie trotzdem.