robots.txt im Next.js App Router, Crawl-Budget und Disallow-Fallen (2026)

TL;DR

robots.txt sagt Crawlern, welche Pfade sie abrufen dürfen, es ist kein Privacy-Tool (dafür noindex + Auth). Im Next.js App Router generieren Sie es mit app/robots.ts (MetadataRoute.Robots), verweisen auf die Sitemap und begrenzen bewusst /api/, Staging und Admin. Ein versehentliches Disallow: / in Produktion oder blockiertes CSS/JS zerstört Indexierung und Rendering. Unten: Crawl-Budget für Service-Sites, sichere vs. gefährliche Regeln, Staging vs. Produktion auf DevStudioIT Cloud und eine Search-Console-Checkliste.

Für wen

• Next.js-(App-Router-)Entwickler mit technischem SEO
• Firmen nach Migration/Redesign oder mit „Discovered, not indexed“
• Teams mit getrenntem Staging und Produktion
• SEOs, die Crawl-Budget bei wachsendem Blog/Katalog steuern
• Alle, die ein Tutorial-Disallow: / auf Live gelassen haben

Keyword (SEO)

robots.txt nextjs app router, crawl budget google 2026, disallow robots.txt fehler, metadataroute robots, search console robots.txt, staging noindex

Was robots.txt kann, und nicht kann

Eine URL kann trotz Disallow im Index erscheinen (z. B. über Backlinks), oft ohne Snippet. Entfernung: noindex und optional GSC Removals.

Crawl-Budget, muss ein Dienstleister sich sorgen?

Bei 50–500 URLs (Angebot + Blog + Case Studies) ist Crawl-Budget selten der Engpass. Relevant wird es bei:

• Query-Parametern (?utm_, Filter, Sortierung) als eigene URLs
• Facetten-Navigation über Leistungen / Städte
• CMS mit tausenden Tags und paginierten Archiven
• Staging/Preview, das ins öffentliche Internet leakt
• APIs und Assets, die wie HTML-Seiten gecrawlt werden

Ziel von robots.txt: Crawls nicht an /api/, Preview, Admin, Parameter-Duplikate verschwenden, damit Google häufiger Angebot, Blog und Landings besucht.

Dynamische Inhalte (Case Studies aus PostgreSQL in Branchly) gehören trotzdem in die Sitemap, robots erfindet diese URLs nicht.

Next.js App Router, app/robots.ts

import type { MetadataRoute } from 'next';

const BASE = 'https://devstudioit.com';
const allowIndexing = process.env.ALLOW_INDEXING === 'true';

export default function robots(): MetadataRoute.Robots {
  if (!allowIndexing) {
    return {
      rules: { userAgent: '*', disallow: '/' },
      // keine Sitemap auf Staging
    };
  }

  return {
    rules: [
      {
        userAgent: '*',
        allow: '/',
        disallow: ['/api/', '/admin/', '/draft/', '/preview/'],
      },
    ],
    sitemap: `${BASE}/sitemap.xml`,
    host: BASE,
  };
}

ALLOW_INDEXING=true nur in Produktion (DevStudioIT Cloud). Staging: Disallow: / und robots: { index: false } in Metadata, Defense in Depth.

Disallow-Regeln, sicher vs. Fallen

Sicher (typische Unternehmenssite)

User-agent: *
Allow: /
Disallow: /api/
Disallow: /admin/
Disallow: /draft/
Sitemap: https://devstudioit.com/sitemap.xml

Gefährlich

Next.js liefert JS/CSS unter /_next/static/.... /_next/ nie blocken.

Trailing Slash und Locales

Ist das Canonical https://example.com/de/leistungen (ohne Slash), erfinden Sie keine Disallow-only-Logik für Slash-Varianten, nutzen Sie 301 + Canonical. robots.txt löst keine PL/EN/DE-Duplikate.

robots.txt und Sitemap

Die Zeile Sitemap: beschleunigt Discovery, aber:

1. Sitemap-URLs überschreiben Disallow nicht, gesperrte URLs dürfen nicht in der Sitemap stehen
2. Prüfen, dass Staging-Sitemaps nicht von Produktion verlinkt sind
3. Nach großem Republish: GSC → Sitemaps → discovered URLs prüfen

Verifikation in Google Search Console

1. Indexierungsgründe auf „Blocked by robots.txt“ prüfen
2. URL Inspection → gecrawlte Seite / robots-Zeile
3. Pfade testen: /, /api/health, /de/blog/...
4. Nach Regeländerungen Re-Crawl abwarten; Indexierung nur für Kern-URLs beantragen

robots.txt, Middleware und Locales

Bei [locale]-Middleware mit Redirect / → /de sicherstellen:

• robots.txt ist unter der Domain-Root erreichbar (https://domain/robots.txt)
• app/robots.ts liefert die Datei außerhalb des Locale-Präfixes
• Sie sperren keine Locale-Pfade, die indexiert werden sollen

Cached das CDN auf DevStudioIT Cloud robots.txt, nach Regeländerungen purgen, sonst sieht Googlebot lange die alte Version.

Staging-Subdomain

# staging.example.com/robots.txt
User-agent: *
Disallow: /

Nie 1:1 auf Produktion kopieren. ALLOW_INDEXING + eigene Staging-Domain verhindert Index-Leaks nach Redesigns.

Produktions-Checkliste

1. ALLOW_INDEXING=true nur auf Prod
2. app/robots.ts erlaubt Site, sperrt /api/, Admin, Draft
3. Kein Disallow auf /_next/
4. Sitemap: zeigt auf Produktions-/sitemap.xml
5. Staging: Disallow all + noindex + eigene Domain
6. Keine gesperrten URLs in der Sitemap
7. GSC: keine kritischen robots-Blocks auf Angebot/Blog
8. Nach Deploy: curl https://domain/robots.txt und manuell prüfen
9. CDN-Cache für /robots.txt nach Änderungen purgen
10. /pl, /en, /de sind Allow

FAQ

Reicht robots.txt für das Kundenportal?

Nein. Portal braucht Auth + noindex + Disallow. Secrets gehören nie ins HTML.

UTMs in robots.txt sperren?

Besser UTMs kanonikalisieren (Canonical ohne Parameter) und interne Links ohne UTM. Disallow: /*?* ist oft zu aggressiv.

Googlebot vs. andere Bots

Sie können User-agent: Googlebot trennen, aber * reicht meist. Überdifferenzierung erschwert Debug.

Was ist mit AI-Crawlern (GPTBot usw.)?

Geschäftliche Policy: Allow/Disallow separat. Nicht mit Google-Search-Crawling verwechseln.

CTA

Audit von robots.txt, Sitemap und Next.js-Indexierung in Produktion?

• Crawl-/GSC-Audit buchen, robots.ts, Staging vs. Prod, DevStudioIT Cloud