Next.js-Google-Indexierung: Der komplette Guide für App Router und Pages Router
Navigier SSG, SSR, ISR und Client Components, damit jede Route für Google entdeckbar wird
In dieser Anleitung
Next.js ist das beliebteste React-Framework für Produktiv-Apps, und sein Rendering-Modell -- das SSG, SSR, ISR und Client-Side-Rendering umspannt -- schafft sowohl mächtige Möglichkeiten als auch subtile Indexierungs-Fallen. Manche Routes liefern beim ersten Request perfektes HTML; andere senden eine leere Hülle, die JavaScript-Ausführung benötigt.
Dieser Guide behandelt sowohl den App Router als auch den Pages Router und führt durch die Metadata API, generateStaticParams, programmatische Sitemaps mit sitemap.ts, robots.ts-Konfiguration, strukturierte Daten und die spezifischen Fallstricke, die dazu führen, dass Next.js-Seiten für Googlebot leer aussehen.
Rendering-Strategien und ihr Einfluss auf die Indexierung
Next.js bietet vier Rendering-Strategien, und jede hat andere Implikationen dafür, wie (und ob) Googlebot deinen Content sieht.
Static Site Generation (SSG) ist der Goldstandard für die Indexierung. Seiten werden zur Build-Zeit zu komplettem HTML gerendert und als statische Dateien ausgeliefert. Googlebot erhält sofort vollständig geformtes HTML -- keine JavaScript-Ausführung nötig. Im App Router wird jede Server Component, die keine dynamischen Funktionen aufruft (wie cookies(), headers() oder searchParams), standardmäßig statisch gerendert. Im Pages Router erreichst du SSG, indem du getStaticProps exportierst.
Server-Side Rendering (SSR) generiert HTML bei jedem Request. Googlebot erhält genau wie bei SSG vollständiges HTML, aber die Seite wird nicht gecacht (es sei denn, du fügst Cache-Header hinzu). SSR wird im App Router durch dynamische Funktionen oder das Setzen von export const dynamic = "force-dynamic" auf einem Route-Segment ausgelöst. Im Pages Router nutzt du getServerSideProps. SSR ist verlässlich für die Indexierung, aber langsamer als SSG, weil jeder Crawl-Request ein vollständiges Render auslöst.
Incremental Static Regeneration (ISR) ist ein Hybrid: Die Seite wird zur Build-Zeit statisch generiert, aus dem Cache ausgeliefert und im Hintergrund nach einem konfigurierbaren Zeitintervall regeneriert. Im App Router erreichst du ISR, indem du export const revalidate = 3600 (in Sekunden) auf einer Seite oder einem Layout setzt. Im Pages Router fügst du revalidate zum Rückgabewert von getStaticProps hinzu. ISR ist exzellent für die Indexierung -- Googlebot bekommt schnelles statisches HTML, und der Content bleibt einigermaßen frisch.
Client-Side-Rendering (CSR) ist dort, wo Indexierungs-Probleme entstehen. Wenn eine Komponente mit "use client" markiert ist und Daten in einem useEffect-Hook fetcht, enthält das initiale HTML, das an den Browser (und an Googlebot) gesendet wird, nichts außer einem Loading State. Googlebot kann JavaScript bis zu einem gewissen Grad ausführen, verarbeitet es aber in einem zweiten Indexierungs-Durchgang, der Stunden oder Tage später stattfinden kann -- und komplexes clientseitiges Data Fetching scheitert in Googles Rendering-Umgebung oft still und leise.
Die Regel: Jeder Content, den du indexiert haben willst, muss im initialen servergerenderten HTML vorhanden sein, nicht per Client-Side-JavaScript nach der Hydration geladen werden.
Die Metadata API: generateMetadata und statische Metadaten
Der App Router hat eine mächtige Metadata API eingeführt, die die alte <Head>-Komponente aus dem Pages Router ersetzt. Es gibt zwei Wege, Metadaten zu definieren: statische Exports und die dynamische generateMetadata-Funktion.
Für statische Metadaten exportier ein metadata-Objekt aus einer page.tsx- oder layout.tsx-Datei. Das funktioniert gut für Seiten mit bekannten, festen Metadaten.
Für dynamische Routes, bei denen Metadaten von Daten abhängen (wie ein Blog-Post-Slug), nutz generateMetadata. Diese async-Funktion bekommt die Route-Params und kann Daten fetchen, um Metadaten dynamisch zu konstruieren.
Ein entscheidender Punkt: generateMetadata läuft auf dem Server, also wird sie für Googlebot-Requests immer ausgeführt. Setzt du Metadaten stattdessen in einer "use client"-Komponente über document.title oder einen Drittanbieter-Head-Manager, übernimmt Googlebot sie beim initialen HTML-Parse möglicherweise nicht. Definier Metadaten immer über die serverseitige Metadata API.
Die Metadata API unterstützt die volle Bandbreite an Meta-Tags:
titleunddescriptionopenGraphundtwitterfür Social Sharingrobotsfür Indexierungs-Kontrollealternatesfür hreflang und Canonical-URLsverificationfür Google Search Consoleiconsfür Favicons
Für Canonical-URLs nutz das Feld alternates.canonical. Für Seiten mit Sprachvarianten füll alternates.languages mit einer Map aus Locale-Codes zu URLs.
Im Pages Router werden Metadaten gehandhabt, indem du Head aus "next/head" importierst und Meta-Tags innerhalb deiner Komponente darin platzierst. Das funktioniert weiterhin, hat aber Grenzen: Head-Inhalte werden erst nach dem React-Rendering verarbeitet, und komplexe verschachtelte Head-Komponenten können zu Tag-Duplikaten führen. Wenn du ein neues Projekt startest, nutz die Metadata API des App Routers.
Sitemaps mit sitemap.ts und sitemap.xml generieren
Der Next.js App Router unterstützt programmatische Sitemap-Generierung über eine spezielle sitemap.ts-Datei (oder sitemap.xml/route.ts), die im app-Verzeichnis platziert wird. Der einfachste Ansatz ist, app/sitemap.ts zu erstellen, die eine Default-Funktion exportiert, die ein Array von Sitemap-Einträgen zurückgibt.
Das generiert automatisch /sitemap.xml. Die Funktion läuft im Development zur Request-Zeit und in Production zur Build-Zeit (für statische Exports) oder bei jedem Request (für dynamisches Rendering).
Für große Sites mit mehr als 50.000 URLs nutz das Sitemap-Index-Muster. Erstell app/sitemap.ts, die einen Sitemap-Index zurückgibt, der auf mehrere Sub-Sitemaps zeigt, und erstell dann einzelne Route Handler für jede Sub-Sitemap (z. B. app/sitemaps/[id]/route.ts). Googles Sitemap-Spezifikation erlaubt bis zu 50.000 URLs pro Sitemap-Datei und bis zu 500 Sitemap-Dateien in einem Index.
Der entscheidende Fehler, den Entwickler machen, ist, dynamische Routes in der Sitemap zu vergessen. Hat deine App eine Route wie /blog/[slug], muss die Sitemap-Funktion deine Datenbank oder dein CMS abfragen, um jeden gültigen Slug zu bekommen und für jeden URLs zu generieren. /blog/[slug] einfach in der Sitemap aufzulisten, ist sinnlos -- Google braucht die tatsächlichen, aufgelösten URLs.
Im Pages Router gibt es keine eingebaute Sitemap-Generierung. Du hast zwei Optionen:
- Nutz das npm-Paket
next-sitemap(generiert Sitemaps zur Build-Zeit durch Auslesen deines pages-Verzeichnisses und dergetStaticPaths-Ausgabe) - Erstell eine eigene API-Route unter
pages/api/sitemap.ts, die XML dynamisch generiert
Das Paket next-sitemap ist die häufigste Wahl und unterstützt serverseitige Sitemaps, robotsTxt-Generierung und das Aufteilen mehrerer Sitemaps.
Dynamische Routes: generateStaticParams und Fallback-Verhalten
Dynamische Routes (app/blog/[slug]/page.tsx) sind die häufigste Quelle für Indexierungs-Lücken in Next.js-Anwendungen. Ohne korrekte Konfiguration werden dynamische Routes möglicherweise nicht zur Build-Zeit vorgerendert, was bedeutet, dass Googlebot beim ersten Besuch entweder eine 404 oder einen Loading State antrifft.
Im App Router exportier eine generateStaticParams-Funktion aus deiner dynamischen Seite, um bestimmte Pfade zur Build-Zeit vorzurendern. Jeder Slug, den diese Funktion zurückgibt, wird zu einer statisch generierten Seite.
Aber was ist mit Slugs, die nicht in generateStaticParams existieren? Das wird durch den dynamicParams-Export gesteuert:
- `dynamicParams = true` (Default) -- Next.js versucht, unmatched Slugs on demand serverseitig zu rendern und das Ergebnis zu cachen
- `dynamicParams = false` -- unmatched Slugs liefern eine 404
Für SEO ist der Default (true) meist richtig, weil er erlaubt, dass neu veröffentlichter Content ohne Full Rebuild gerendert wird.
Im Pages Router ist das Äquivalent getStaticPaths mit einem fallback-Parameter:
- `fallback: false` -- liefert 404 für unbekannte Pfade
- `fallback: true` -- rendert beim ersten Request eine Loading-Seite (Googlebot sieht den Loading State, was schrecklich für die Indexierung ist)
- `fallback: "blocking"` -- blockiert die Response, bis die Seite vollständig gerendert ist, und cacht sie dann
Für SEO nutz im Pages Router immer `fallback: "blocking"`.
Das Zusammenspiel zwischen generateStaticParams und ISR ist wichtig. Setzt du revalidate auf einer dynamischen Seite, regenerieren sich vorgerenderte Seiten nach der Revalidierungs-Periode im Hintergrund. Neue Slugs, die nicht in generateStaticParams stehen, werden beim ersten Request gerendert (wenn dynamicParams true ist) und dann mit ISR gecacht. Diese Kombination gibt dir das Beste aus beiden Welten: schnelles statisches Ausliefern für bekannte Seiten und On-Demand-Rendering für neuen Content.
robots.ts, Noindex-Regeln und Crawl-Kontrolle
Der App Router unterstützt eine robots.ts-Datei unter app/robots.ts, die programmatisch /robots.txt generiert.
Wichtige Next.js-spezifische Überlegungen für robots.txt:
- Blockier immer
/api/-Routes (sie liefern JSON, kein HTML) - Blockier
/_next/data/(JSON-Daten für clientseitige Navigation, die nicht als eigenständige Seiten indexiert werden sollten) - Blockier alle authentifizierten Dashboard-Routes
- Blockier NICHT
/_next/static/-- dort liegen CSS- und JS-Dateien, die Googlebot zum korrekten Rendern deiner Seiten braucht
Für Noindex-Kontrolle auf Seiten-Ebene nutz das Feld robots in der Metadata API. Setz robots: { index: false } im Metadata-Export jeder Seite, die du aus Suchergebnissen ausschließen willst. Das passt für:
- Authentifizierungs-Seiten (
/login,/register) - User-Dashboards
- API-Dokumentation hinter Auth
- Jede Seite mit personalisiertem Content
Middleware (middleware.ts im Projekt-Root) kann ebenfalls die Indexierung beeinflussen. Macht deine Middleware Redirects für Auth oder Locale-Erkennung, stell sicher, dass Googlebot nicht in Redirect-Loops gefangen wird.
Ein gängiges, sicheres Muster ist Middleware, die nicht authentifizierte Nutzer von /dashboard zu /login umleitet -- das ist okay, weil du /dashboard sowieso noindexed haben willst. Aber Middleware, die basierend auf Geolocation umleitet, kann Googlebot (der von US-IPs crawlt) so einfangen, dass er immer die US-Version sieht und andere Locale-Versionen nie indexiert werden.
Test dein Middleware-Verhalten mit dem URL-Prüftool der Google Search Console, um genau zu sehen, was Googlebot antrifft.
Strukturierte Daten und Open Graph für Rich Search Results
Strukturierte Daten (JSON-LD) sind entscheidend, um in Google Rich Results zu erhalten: Sterne-Bewertungen, FAQ-Akkordeons, Breadcrumbs, Artikel-Veröffentlichungsdaten und mehr. Im App Router ist der sauberste Ansatz, eine JsonLd-Server Component zu erstellen, die ein <script type="application/ld+json">-Tag rendert.
Diese Komponente sollte typisierte Props akzeptieren, die zu Schema.org-Typen passen (Article, FAQPage, Product, BreadcrumbList, Organization), und sie in das Script-Tag serialisieren. Weil es eine Server Component ist, ist das JSON-LD im initialen HTML enthalten, das Googlebot erhält -- keine clientseitige Ausführung nötig.
Für Open-Graph-Tags nutz das Feld openGraph in deinem Metadata-API-Export. Schließ ein:
og:titleundog:descriptionog:image(mit Maßen)og:url,og:typeundog:locale
Für Twitter Cards nutz das Feld twitter. Diese Tags müssen im HTML-<head> vorhanden sein, was die Metadata API automatisch erledigt.
Ein häufiger Fehler in Next.js-Apps ist, strukturierte Daten clientseitig zu generieren. Wenn du eine "use client"-Komponente nutzt, um Produkt-Reviews zu fetchen und dann einen JSON-LD-Block mit dem aggregierten Rating zu generieren, enthält Googlebots initialer HTML-Parse die strukturierten Daten möglicherweise nicht. Generier strukturierte Daten immer in Server Components oder in `generateMetadata`. Googles Rich Results Test lässt dich bestimmte URLs testen, um zu verifizieren, dass deine strukturierten Daten für Crawler sichtbar sind.
Breadcrumb-strukturierte-Daten sind besonders wertvoll für Next.js-Apps mit verschachtelten Routes. Hat deine App-Struktur /blog/kategorie/post-slug, generier ein BreadcrumbList-Schema mit Items für Home, Blog, die Kategorieseite und den aktuellen Post. Das gibt Google explizite Navigations-Hierarchie-Informationen und kann zu Breadcrumb-Anzeige in Suchergebnissen statt der rohen URL führen.
Schritt-für-Schritt-Anleitung
Deine Rendering-Strategie pro Route auditieren
Prüf next.config.ts auf globale Output-Einstellungen. Geh jede page.tsx durch und klassifizier sie: dynamische Funktionen = SSR, revalidate-Export = ISR, generateStaticParams = vorgerendert, "use client" mit useEffect-Data-Fetching = CSR (Indexierungs-Risiko). Bau eine Tabelle jeder Route, ihrer Strategie und ob kritischer Content im initialen HTML auftaucht.
Die Metadata API auf jeder Route implementieren
Ergänze in jeder page.tsx und layout.tsx deines App Routers entweder einen statischen Metadata-Export oder eine generateMetadata-Funktion. Minimum: Jede Seite braucht einen einzigartigen Title und eine Description.
- Für dein Root-Layout (
app/layout.tsx) setz Default-Metadaten viatitle.template(z. B.title: { template: "%s | DeineApp", default: "DeineApp" }) - Für dynamische Routes wie
/blog/[slug]implementiergenerateMetadata, das den Content fetcht und seitenspezifische Metadaten zurückgibt - Ergänze
alternates.canonicalauf jeder Seite, um die Canonical-URL explizit zu definieren - Unterstützt deine App mehrere Sprachen, füll
alternates.languages
Setz Metadaten nicht in "use client"-Komponenten -- nutz immer serverseitige Metadata-Exports.
sitemap.ts und robots.ts erstellen
Erstell app/sitemap.ts, die eine async Default-Funktion exportiert, die ein Array von Sitemap-Einträgen zurückgibt. Frag deine Datenbank oder dein CMS nach allem dynamischen Content (Blog-Posts, Produkt-Seiten, Kategorieseiten) und generier für jeden eine vollständige URL.
Setz Prioritäts-Werte:
- 1,0 für die Startseite
- 0,8-0,9 für Key Landingpages
- 0,5-0,7 für regulären Content
Inkludier lastModified-Daten für jeden Eintrag.
Erstell app/robots.ts, die Regeln zurückgibt, die /api/, /_next/data/, /admin/ und alle authentifizierten Routes blockieren, während alles andere erlaubt ist und deine Sitemap-URL angegeben wird.
Deploy und verifizier, dass /sitemap.xml valides XML und /robots.txt valide Direktiven liefert, indem du sie im Browser aufrufst.
Dynamische Routes mit generateStaticParams vorrendern
Exportier generateStaticParams aus jeder dynamischen Route, um gültige Pfade zur Build-Zeit vorzurendern. Kombinier mit dynamicParams: true und revalidate, damit neuer Content beim ersten Request servergerendert und via ISR gecacht wird. Im Pages Router nutz fallback: "blocking" statt fallback: true, um Googlebot keine Loading States auszuliefern.
Kritischen Content aus Client Components herausholen
Geh jede "use client"-Komponente durch, die Content anzeigt, den du indexiert haben willst. Fetcht die Komponente Daten über useEffect, useSWR oder React Query und rendert sie clientseitig, sieht Googlebot diesen Content möglicherweise nicht.
Refactor-Muster: Verschieb das Data Fetching in eine Server Component-Eltern-Komponente und reich die Daten als Props an die Client Component weiter. Die Client Component kann weiterhin Interaktivität handhaben (Click-Handler, State), aber der initiale Content sollte im servergerenderten HTML vorhanden sein.
Test: Deaktivier JavaScript in deinem Browser und lad jede Seite. Was du ohne JavaScript siehst, ist ungefähr das, was Googlebot beim initialen HTML-Parse sieht.
Strukturierte Daten für Rich Results ergänzen
Erstell eine wiederverwendbare Server Component für JSON-LD-strukturierte-Daten. Ergänze die passenden Schema-Typen:
- Blog-Posts --
Article-Schema mitheadline,author,datePublished,dateModifiedundimage - Produktseiten --
Product-Schema mitname,description,priceundaggregateRating - Alle verschachtelten Seiten --
BreadcrumbList-Schema für Navigations-Hierarchie - Startseite --
Organization-Schema
Validier jede strukturierte-Daten-Implementierung mit Googles Rich Results Test, indem du deine Live-URLs eingibst. Behebe alle Fehler oder Warnungen, bevor du weitermachst.
Denk dran: Alle strukturierten Daten müssen in Server Components stehen, damit sie im initialen HTML erscheinen.
Kritische URLs via IndexBolt einreichen und monitoren
Reich deine Startseite, Key Landingpages und High-Priority-Content über IndexBolt ein. Bei einer neuen App bringt das Bootstrapping von 20-50 URLs Googles Verständnis Tage schneller voran. Beobachte in der URL-Prüfung der Search Console -- verifizier, dass der Seiten-Fetch komplettes HTML zeigt, keine Loading States. Untersuch alle Routes mit Status „Gefunden -- zurzeit nicht indexiert“ auf Rendering-Probleme.
Häufige Probleme und wie du sie behebst
Seiten zeigen Googlebot leeren Content oder Loading Spinner
Ursache: Content wird in einer „use client“-Komponente per useEffect oder einer clientseitigen Data-Fetching-Library gefetcht. Das initiale servergerenderte HTML enthält nur den Loading State (einen Spinner, ein Skeleton oder ein leeres Div). Googlebots initialer HTML-Parse sieht keinen Content, und sein zweiter JavaScript-Rendering-Durchgang kann wegen API-Authentifizierung, CORS-Issues oder Rendering-Timeout fehlschlagen.
Lösung: Verschieb das Data Fetching in Server Components oder nutz generateStaticParams mit statischer Generierung. Reich Daten als Props an Client Components weiter, die Interaktivität brauchen. Im Pages Router nutz getStaticProps oder getServerSideProps statt clientseitiges Fetching. Test, indem du den Seitenquelltext anschaust (nicht das gerenderte DOM in DevTools) -- der Source sollte deinen tatsächlichen Content-Text enthalten.
Dynamische Routes liefern 404 für Seiten, die nicht in generateStaticParams sind
Ursache: Die dynamische Route hat export const dynamicParams = false gesetzt, was bedeutet, dass jeder von generateStaticParams nicht zurückgegebene Slug eine 404 erzeugt. Im Pages Router verhält sich getStaticPaths mit fallback: false genauso. Neu veröffentlichter Content, der zur Build-Zeit nicht vorhanden war, ist unerreichbar.
Lösung: Setz dynamicParams auf true (Default) und ergänze eine revalidate-Periode, damit neu generierte Seiten via ISR gecacht werden. Im Pages Router wechsel von fallback: false zu fallback: „blocking“. Stell dann sicher, dass deine sitemap.ts dynamisch nach allem aktuellen Content abfragt, damit neue Seiten in der Sitemap auftauchen, auch wenn sie zur Build-Zeit nicht vorgerendert wurden.
Sitemap enthält keine dynamisch generierten Seiten
Ursache: Die sitemap.ts wurde mit einer statischen Liste von URLs geschrieben und fragt nicht die Datenbank oder das CMS nach dynamischem Content ab. Oder die Sitemap wurde zur Build-Zeit mit next-sitemap generiert, aber der Build wurde nach Veröffentlichung neuer Inhalte nicht erneut ausgeführt. Neue Blog-Posts, Produktseiten oder Kategorieseiten fehlen in der Sitemap.
Lösung: Schreib sitemap.ts so um, dass sie deine Content-Quelle (Datenbank, Headless-CMS-API oder Dateisystem) bei jedem Request dynamisch abfragt. Bei ISR-basierten Sites setz revalidate auf der Sitemap-Route, damit sie periodisch regeneriert. Nutzt du next-sitemap im Pages Router, konfigurier serverseitige Sitemap-Generierung oder richte einen Cron-Job ein, der Rebuilds bei Content-Änderungen triggert.
Middleware-Redirects verhindern, dass Googlebot auf Locale-spezifische Seiten zugreift
Ursache: Locale-Erkennungs-Middleware liest den Accept-Language-Header oder nutzt IP-basierte Geolocation, um Besucher auf einen Locale-spezifischen Pfad umzuleiten (z. B. /en-us/, /fr/). Googlebot crawlt primär von US-IPs mit englischen Headern, wird also immer auf die US-Englisch-Version umgeleitet. Seiten für andere Locales werden nie gecrawlt oder indexiert.
Lösung: Leite Googlebot nicht basierend auf Geolocation oder Accept-Language um. Liefer stattdessen den Default-Locale-Content und verlass dich auf hreflang-Tags (gesetzt über alternates.languages in der Metadata API), um Google über Locale-Varianten zu informieren. In deiner Middleware kannst du den User-Agent auf Googlebot prüfen und Locale-Redirects für ihn überspringen, oder besser: nutz hreflang als primäres Locale-Signal und Middleware-Redirects nur als Komfortlösung für echte Nutzer.
loading.tsx-Dateien zeigen Platzhalter-Content, der indexiert wird
Ursache: Der Next.js App Router nutzt loading.tsx, um über React Suspense sofortige Loading-UI anzuzeigen, während eine Seite gerendert wird. Nutzt die Seite SSR (dynamisches Rendering), erhält Googlebots initialer Request möglicherweise den loading.tsx-Content statt der tatsächlichen Seite. Das ist besonders wahrscheinlich bei Seiten mit langsamem Data Fetching.
Lösung: Für Seiten mit kritischem SEO-Content bevorzug statische Generierung oder ISR gegenüber dynamischem Rendering. Ist dynamisches Rendering nötig, stell sicher, dass das Data Fetching schnell abschließt (unter 5 Sekunden), damit die Streaming-Response tatsächlichen Content vor Googlebots Timeout liefert. Erwäg, schweres Data Fetching in Client Components zu verlagern, die die Seite verbessern, nachdem der kritische servergerenderte Content schon da ist.
Next.js-Image-Komponente erzeugt URLs, die Crawl-Budget verstopfen
Ursache: Die Next.js-Image-Komponente optimiert Bilder über /_next/image?url=...&w=...&q=...-Pfade. Jede Breiten- und Qualitäts-Kombination erzeugt eine einzigartige URL. Werden diese URLs nicht in robots.txt blockiert, verbrennt Googlebot möglicherweise Crawl-Budget mit dem Fetchen von Bild-Optimierungs-Endpoints statt tatsächlichem Seiten-Content.
Lösung: Ergänze Disallow: /_next/image in deiner robots.ts, um Googlebot vom direkten Crawlen der Bild-Optimierungs-URLs abzuhalten. Die tatsächlichen Bilder, die in den <img>-Tags deiner Seiten referenziert sind, bleiben über das HTML deiner Seiten entdeckbar und indexierbar. Das spart auf bildlastigen Sites erhebliches Crawl-Budget.
Profi-Tipps
Eine neue Next.js-App deployed oder dynamische Routes ergänzt? Google kann Wochen brauchen, um on-demand gerenderte Seiten zu entdecken. Nutz IndexBolt, um deine frisch gebauten Seiten direkt in Googles Indexierungs-Queue zu schieben -- besonders kritisch für SSR- und ISR-Routes, die keinen Build-Time-URL-Footprint haben.
100 Gratis-Credits. Keine Kreditkarte nötig. Ergebnisse in unter 24 Stunden.
Häufig gestellte Fragen
Führt Googlebot JavaScript in Next.js-Anwendungen aus?+
Ja, Googlebot hat eine JavaScript-Rendering-Engine, die auf einer aktuellen Chromium-Version basiert. JavaScript-Rendering passiert aber in einem zweiten Indexierungs-Durchgang, der Stunden oder sogar Tage nach dem initialen HTML-Crawl stattfinden kann. Das heißt: Content, der nur nach JavaScript-Ausführung erscheint, wird mit Verzögerung indexiert -- und komplexes clientseitiges Data Fetching (besonders zu authentifizierten APIs) kann in Googles Rendering-Umgebung komplett scheitern. Für verlässliche Indexierung stell sicher, dass aller kritische Content im initialen servergerenderten HTML steht -- via Server Components, getStaticProps oder getServerSideProps.
Soll ich den App Router oder den Pages Router für besseres SEO nutzen?+
Der App Router hat überlegenes SEO-Tooling, inklusive der eingebauten Metadata API, sitemap.ts, robots.ts und Server Components, die Content standardmäßig serverseitig rendern. Der Pages Router funktioniert für SEO gut, braucht aber mehr Handarbeit: Du brauchst die next/head-Komponente für Metadaten, Drittanbieter-Pakete wie next-sitemap für Sitemaps und getStaticProps/getServerSideProps für Server-Rendering. Für neue Projekte ist der App Router die klare Wahl. Für bestehende Pages-Router-Projekte gibt es keinen dringenden Migrationsbedarf -- fokussier dich darauf, korrektes getStaticProps/getServerSideProps und eine funktionierende Sitemap zu haben.
Wie beeinflusst ISR die Google-Indexierung?+
Incremental Static Regeneration ist exzellent für die Indexierung. Googlebot erhält sofort statisch gecachtes HTML (schnelle Antwortzeit verbessert die Crawl-Effizienz), und der Content regeneriert sich im Hintergrund, um frisch zu bleiben. Die einzige Überlegung ist die Revalidierungs-Periode: Setzt du revalidate auf 3600 (eine Stunde), können Content-Änderungen bis zu einer Stunde brauchen, um in der gecachten Seite zu erscheinen. Für zeitkritischen Content nutz eine kürzere Revalidierungs-Periode oder triggere On-Demand-Revalidierung via Webhooks. Aus Googles Sicht verhalten sich ISR-Seiten identisch zu statischen Seiten -- sie sind schnell, vollständig gerendert und verlässlich.
Meine Next.js-Seiten zeigen in der Search Console „Gefunden -- zurzeit nicht indexiert“. Warum?+
Dieser Status bedeutet, dass Google die URL gefunden hat (über deine Sitemap oder interne Links), sie aber noch nicht gerendert und indexiert hat. Bei Next.js-Apps passiert das oft, wenn: (1) die Seite Client-Side-Rendering nutzt und Googlebots initialer HTML-Crawl keinen Content fand, sodass die Seite deprioriert wurde; (2) die Seite Thin Content hat, den Google als minderwertig einstuft; (3) deine Site neu ist und Google noch nicht genug Crawl-Budget zugewiesen hat; oder (4) die Seite einen Canonical-Tag hat, der woanders hinzeigt. Nutz das URL-Prüftool, um die Seite als Googlebot zu fetchen und das gerenderte HTML zu prüfen. Ist es leer oder zeigt einen Loading State, hast du ein Rendering-Problem zu beheben.
Wie handhabe ich Canonical-URLs in Next.js für Seiten mit Query-Parametern?+
In der App-Router-Metadata-API setz alternates: { canonical: „https://deinedomain.de/seite“ } ohne Query-Parameter. Das sagt Google, dass die Basis-URL die kanonische Version ist, unabhängig von Tracking-Parametern, Paginierung oder Filter-Parametern, die angehängt werden. Bei Seiten, wo Query-Parameter sinnvoll unterschiedlichen Content erzeugen (wie paginierte Suchergebnisse), generier entweder einzigartige Canonical-URLs für jede Seite (alternates: { canonical: „https://deinedomain.de/search?page=2“ }) oder nutz einen einzigen Canonical, der auf Seite 1 zeigt, und verlass dich auf interne Links, damit Google nachfolgende Seiten entdeckt.
Kann ich IndexBolt mit Next.js nutzen, um die Indexierung neuer Seiten zu beschleunigen?+
Absolut. IndexBolt ist für Next.js-Anwendungen besonders wertvoll, weil viele Next.js-Sites ISR oder On-Demand-Rendering nutzen, was bedeutet, dass neue Seiten keine statischen URLs haben, die Google über klassisches Crawling entdeckt. Nach dem Veröffentlichen neuer Inhalte nutz die IndexBolt-API oder das Dashboard, um die URLs direkt an Googles Indexierungs-Pipeline zu übermitteln. Das ist besonders effektiv für on-demand generierte E-Commerce-Produktseiten, neue Blog-Posts in einem Headless-CMS-Setup oder Landingpages, die als Teil eines Feature-Launches deployed werden. Der Normal-Modus funktioniert für Routine-Content; nutz den Instant-Modus für Produkt-Launches oder zeitkritische Seiten.