Prüfen Sie, was Ihre Next.js-Website an die Suche ausliefert.

Was prüft ein Next.js-SEO-Audit?

Das Audit prüft, was jede der stichprobenartig gewählten Routen Ihrer Website an einen Crawler ausliefert: das HTML in der Antwort, die Tags im Head-Bereich, Ihre Indizierungssignale und das Gewicht Ihrer Skripte. Öffnen Sie den Quelltext Ihrer Startseite und suchen Sie nach Ihrer Hauptüberschrift. Finden Sie sie? Dann hat Ihr Server sie gesendet. Sehen Sie dagegen nur ein leeres `div`-Element und ein Skriptbündel (was häufig vorkommt), wartet Ihr Inhalt auf die Ausführung von JavaScript.

Die Bewertung analysiert Ihre Antwort-Header, das Markup, strukturierte Daten, Überschriften, das Gewicht von Skripten und Bildern sowie Robots- und Canonical-Signale auf Ihrer Startseite und bis zu acht zufällig ausgewählten Seiten. Diese Messwerte fließen in acht gewichtete Säulen ein, darunter Architektur mit 15 %, Leistung mit 15 %, Suche mit 12 % und Schema mit 10 %. Ihr Repository wird dabei nie geöffnet. Jedes Ergebnis sagt Ihnen deshalb, was ein Crawler von Ihrer Website erhält, und nicht, welche Datei das verursacht hat. Auch die Suchmaschine sieht Ihren Code nie. Und genau diese Sicht zählt für Sie.

Ändert der Rendering-Modus, was Google erhält?

Ja. Ihr Rendering-Modus entscheidet, ob die erste Antwort Ihren Inhalt enthält oder nur eine Hülle, die Google später rendern muss. Rufen Sie eine Ihrer Artikel-URLs ab und suchen Sie im HTML-Code nach dem Fließtext. Beim statischen Rendering erzeugen Sie diesen HTML-Code vorab und legen ihn im Cache ab, beim dynamischen Rendering generieren Sie ihn bei jeder Anfrage neu. Und in beiden Fällen senden Sie Markup (genau darum geht es).

Ihre Probleme beginnen erst, wenn Sie sich ausschließlich auf Abrufe im Client verlassen. Stellen Sie eine Seite auf „use client“ um oder laden Ihre Inhalte innerhalb von useEffect, sieht Googlebot statt Ihres Textes die Meldung „Wird geladen…“. Next.js wählt für jede Ihrer Routen eine Strategie. Rufen Sie eine dynamische API wie Cookies oder Header auf, wechselt diese Route den Modus. So betreiben Sie schneller als gedacht eine gemischte Website, für die Sie sich nie bewusst entschieden haben.

Google führt Ihr JavaScript aus, stellt Ihre Seiten aber erst nach der ersten 200-Antwort in die Warteschlange, und die Wartezeit kann einige Sekunden überschreiten. Die Dokumentation nennt serverseitiges oder vorab durchgeführtes Rendering weiterhin eine hervorragende Idee. Und nicht alle Bots führen JavaScript aus, auf die Ausführung Ihrer Skripte ist also kein Verlass. Die Überprüfung analysiert den Inhalt Ihrer Antwort Route für Route, sodass Sie jede Route sehen, die Sie ausliefern.

Wie legt die Metadata-API Ihre Titel, Canonical-Tags und Open-Graph-Tags fest??

Ihre Head-Tags stammen aus dem Metadatenobjekt oder aus der Funktion „generateMetadata“, die Sie in einer Datei „layout.js“ oder „page.js“ exportieren. Öffnen Sie den Head einer untergeordneten Seite Ihrer Website und suchen Sie Ihren Titel, Ihren kanonischen Link und Ihr „og:image“. Damit lesen Sie Ihre Exporte. Was Sie dort finden, sieht auch die Auswertung auf Ihrer Seite.

Ihre Funktion „generateMetadata“ kann Daten abrufen und die Metadaten Ihrer übergeordneten Seite lesen, sodass Sie ein gemeinsames Open-Graph-Bild erweitern statt ersetzen können. Legen Sie „alternates.canonical“ fest, schreibt Next.js Ihren kanonischen Link; legen Sie „openGraph.images“ fest, schreibt es Ihr „og:image“. Bild-URLs müssen absolut sein, setzen Sie deshalb `metadataBase` mit `new URL(...)`. Ihre `title.template` gilt nur für untergeordnete Segmente. Die Seite in dem Segment, in dem Sie sie definieren, überspringt sie, was manche überrascht. Und wenn Ihre Titel falsch erscheinen, prüfen Sie, wo Sie das Template festgelegt haben.

Statische Metadaten erkennen Sie an einem identischen Titel auf vielen Routen, an einem fehlenden kanonischen Link oder an einem relativen `og:image`-Attribut. Die Auswertung listet diese Punkte auf Ihren Stichprobenseiten auf, und Sie können jede Lücke dem Export dahinter zuordnen. Öffnen Sie dann die Datei der jeweiligen Route und prüfen Sie, was Sie exportiert haben. Jede Lücke geht auf einen Export zurück, den Sie geschrieben (oder versäumt) haben.

Warum fallen Next.js-Websites bei den Core Web Vitals durch?

Ihre Next.js-Website verfehlt die Core Web Vitals, wenn Ihre Felddaten einen LCP-Wert von über 2,5 Sekunden, einen INP-Wert von über 200 Millisekunden oder einen CLS-Wert von über 0,1 zeigen. Vercel gibt an, dass auf Seiten, deren LCP-Element ein Bild war, 35 % dieser Bilder Quell-URLs hatten, die im ursprünglichen HTML-Code nicht auffindbar waren. Prüfen Sie das bei Ihrer eigenen Seite: Suchen Sie im ursprünglichen HTML-Code die URL Ihres größten Bildes im Bereich „Above the Fold“.

Skriptgröße und Hydration bestimmen Ihren INP-Wert, der im März 2024 den FID-Wert abgelöst hat. Laut Vercel hydrieren die Hauptblöcke Ihrer Seite unabhängig voneinander, wenn Sie sie mit Suspense umschließen, und das verbessert Ihren INP-Wert. Die Ursachen Ihres CLS-Werts sind leichter zu finden: Bilder, die Sie ohne Abmessungen ausliefern, Inhalte, die Sie nachträglich einfügen, und Webfonts, die Sie laden. Prüfen Sie Ihre Vorlagen auf alle drei.

Die Auswertung misst die Skript- und Bildgröße Ihrer Seiten, liefert aber keine Felddaten. Google bewertet Ihre Seiten in den Suchergebnissen jedoch anhand von Felddaten aus 28 Tagen. Ein sauberer Lighthouse-Lauf genügt also nicht: Ein gutes Laborergebnis kann einen schlechten Monat verdecken. Führen Sie als Nächstes den Core Web Vitals-Test durch und prüfen Sie Ihre eigenen Felddaten.

Welche App-Router-Fehler verstecken Seiten vor der Suche?

Sie verbergen Seiten vor Suchmaschinen, wenn Sie Inhalte ausschließlich clientseitig rendern, versehentlich „noindex“ setzen, das Crawling dort blockieren, wo Sie eigentlich „noindex“ gewollt hätten, oder doppelte URLs ohne Canonical-Tags lassen. Öffnen Sie Ihre robots.txt-Datei und prüfen Sie, ob Sie JavaScript- oder CSS-Pfade blockieren. Werfen Sie einen Blick in den „head“-Bereich Ihrer wichtigsten Seite und suchen Sie nach einem „robots“-Meta-Tag. Eine einzige falsch platzierte Zeile dort kann all Ihre Bemühungen zunichtemachen (und fällt selten auf).

In Ihrem App-Router setzen Sie „noindex“ pro Seite über einen Metadaten-Export: robots: { index: false, follow: false }. Lassen Sie diese URL in Ihrer Sitemap stehen, senden Sie gemischte Signale. Blockieren Sie sie obendrein in Ihrer robots.txt, ruft Google die Seite womöglich nie ab, und Ihr „noindex“ wird gar nicht erst gelesen. Die beiden Einstellungen heben sich gegenseitig auf.

Vergewissern Sie sich, dass Ihre Staging-Umgebung nicht indexiert ist. Die Überprüfung erfasst die „robots“-Anweisungen und kanonischen Signale Ihrer Startseite und der Stichprobenseiten. Ihr Bericht zeigt Ihnen daher verirrte „noindex“-Angaben, fehlende kanonische Links und rein clientseitige Shells. Routen außerhalb dieser Stichprobe sieht er aber nicht. Die übrigen Routen prüfen Sie bitte selbst.

Wie prüfen Sie eine Next.js-Website in zwei Minuten von außen?

Führen Sie die kostenlose Analyse Ihrer URL durch und geben Sie Ihre geschäftliche E-Mail-Adresse ein. In etwa zwei Minuten erhalten Sie eine Bewertung auf einer Skala von 100, zusammen mit den Belegen für jede Ihrer Säulen. Fügen Sie zunächst Ihre Startseite ein. Vergleichen Sie anschließend die Angaben Ihres Berichts zu Rendering und Head-Tags mit der Quellcode-Ansicht einer Ihrer tiefer liegenden Seiten. Über Ihre E-Mail-Adresse erhalten Sie einmalig den Link zum Bericht. Sie können drei Überprüfungen pro Stunde und Verbindung durchführen.

Lesen Sie zuerst Ihre Bandbreite ab, bevor Sie auf die einzelne Zahl schauen. 80 bis 100 steht für einen guten Zustand, 60 bis 79 für einen eingeschränkten, 40 bis 59 für einen Risikozustand und 0 bis 39 für einen chronischen. Gehen Sie danach die Befunde zu jeder Säule durch und notieren Sie, welche sich auf das Rendering, kanonische URLs oder das Gewicht von Skripten beziehen. Genau dort liegen die Korrekturen mit der größten Wirkung auf Ihre Website.

Was danach kommt, geht über diese Analyse hinaus. Die Auswertung berücksichtigt nur Ihre öffentlichen Seiten und kann deshalb weder Ihre Leistungsdaten aus der Praxis noch Ihren Quellcode bestätigen. Brauchen Sie Zeitangaben? Dann führen Sie den Core Web Vitals-Test durch. Wollen Sie wissen, wie KI-Systeme Ihre Seiten interpretieren? Dann nehmen Sie das KI-SEO-Audit.

Fragen und Antworten.

Weiterlesen.

1. 01Astro-SEO-CheckIslands, Content Collections, strukturierte Daten, Web Vitals.
2. 02Headless-CMS-SEO-AuditRendering, Canonicals, Vorschauen, strukturierte Daten aus dem Template.
3. 03Core Web Vitals-TestLCP, INP und CLS, gemessen an dem, was die Seite ausliefert.