robots.txt w Next.js App Router, crawl budget i pułapki Disallow (2026)

TL;DR

robots.txt mówi crawlerom, które ścieżki wolno pobierać, nie jest narzędziem do „ukrycia” poufnych stron (do tego noindex + auth). W Next.js App Router generujesz go przez app/robots.ts (MetadataRoute.Robots), wskazujesz sitemap i świadomie ograniczasz /api/, staging oraz panele. Błędny Disallow: / na produkcji albo zablokowanie CSS/JS psuje indeksowanie i Core Web Vitals w oczach Google. Poniżej: crawl budget dla stron firmowych, reguły bezpieczne vs niebezpieczne, różnica staging/produkcja na DevStudioIT Cloud oraz checklista Search Console.

Dla kogo

• Developerów Next.js (App Router) odpowiedzialnych za SEO techniczne
• Firm po migracji, redesignie lub z „Discovered, not indexed”
• Zespołów z osobnym stagingiem i produkcją
• SEO dbających o crawl budget przy rosnącym blogu / katalogu
• Osób, które skopiowały Disallow: / z tutoriala i zostawiły na live

Fraza (SEO)

robots.txt nextjs app router, crawl budget google 2026, disallow robots.txt błędy, metadataroute robots, search console robots.txt, staging noindex

Czym robots.txt jest, i czym nie jest

URL w indeksie mimo Disallow nadal może się pojawić (np. z backlinków), często bez snippetu. Żeby usunąć z wyników: noindex + ewentualnie Removal w GSC.

Crawl budget, czy firma usługowa w ogóle musi się martwić?

Dla strony z 50–500 URL-ami (oferta + blog + case studies) crawl budget rzadko jest bottleneckiem. Staje się istotny, gdy:

• Generujesz parametry (?utm_, filtry, sortowanie) jako osobne URL-e
• Masz faceted navigation w katalogu usług / miast
• CMS publikuje tysiące tagów i paginacji
• Staging i preview leakują do internetu
• API i assety są zbędnie crawlowane jako HTML

Cel robots.txt: nie marnować crawli na /api/, preview, admin, duplikaty parametrów, żeby Google częściej wracał na ofertę, blog i landingi.

Dynamiczne treści (case studies z PostgreSQL w Branchly) i tak powinny być w sitemap, robots ich nie „wymyśli”.

Next.js App Router, app/robots.ts

// 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: '/' },
      // bez sitemap na staging
    };
  }

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

Uwaga środowiskowa: ustaw ALLOW_INDEXING=true tylko na produkcji (DevStudioIT Cloud). Staging: Disallow: / oraz robots: { index: false } w metadata, defense in depth.

Reguły Disallow, bezpieczne vs pułapki

Bezpieczne (typowa strona firmowa)

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

Niebezpieczne

Next.js serwuje JS/CSS spod /_next/static/.... Nie blokuj /_next/.

Trailing slash i locale

Jeśli canonical to https://example.com/pl/oferta (bez trailing slash), nie twórz osobnej logiki Disallow tylko dla wariantów slash, lepiej 301 + canonical (osobny artykuł o canonical). robots.txt nie naprawia duplikatów PL/EN/DE.

robots.txt a sitemap

Wskazanie Sitemap: w robots przyspiesza discovery, ale:

1. URL w sitemap nie nadpisuje Disallow, zablokowany URL nie powinien być w sitemap
2. Audytuj: czy staging sitemap nie jest podlinkowany z produkcji
3. Po dużym republishu: GSC → Sitemaps → sprawdź „Discovered URLs”

Weryfikacja w Google Search Console

1. Settings → robots.txt (lub raport „Page indexing” z powodem „Blocked by robots.txt”)
2. URL Inspection → „View crawled page” / robots line
3. Tester robots.txt (jeśli dostępny w property), sprawdź ścieżki /, /api/health, /pl/blog/...
4. Po zmianie reguł: daj czas na re-crawl; „Request indexing” na kluczowych URL

robots.txt a middleware i locale

Na stronach z [locale] middleware często przekierowuje / → /pl. Upewnij się, że:

• robots.txt jest dostępny pod root domeny (https://domena/robots.txt), nie tylko pod /pl/robots.txt
• Next.js app/robots.ts serwuje plik poza locale prefixem, tak działa MetadataRoute
• Nie Disallowujesz ścieżek locale, których chcesz indeksować

Jeśli CDN na DevStudioIT Cloud cache’uje robots.txt, po zmianie reguł zrób purge, inaczej Googlebot może długo widzieć starą wersję.

Przykład: osobne reguły dla staging subdomain

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

Na produkcji nigdy nie kopiuj tego pliku 1:1. Env ALLOW_INDEXING + osobna domena staging to standard, który eliminuje przecieki indeksu po redesignie.

Checklista produkcyjna

1. ALLOW_INDEXING=true tylko na prod
2. app/robots.ts zwraca Allow + Disallow /api/, admin, draft
3. Nie Disallow /_next/
4. Sitemap: wskazuje produkcyjne /sitemap.xml
5. Staging: Disallow all + noindex + osobna domena
6. Brak zablokowanych URL w sitemap
7. GSC: zero krytycznych „Blocked by robots.txt” na ofertę/blog
8. Po deployu: curl https://domena/robots.txt i ręczny przegląd
9. Purge CDN cache dla /robots.txt po zmianie
10. Potwierdź, że locale /pl, /en, /de są Allow

FAQ

Czy robots.txt ukryje panel klienta?

Nie wystarczy. Panel: auth + noindex + Disallow. Hasła i tokeny i tak nie powinny być w HTML.

Czy blokować UTM w robots.txt?

Lepiej kanonikalizować UTM (canonical bez parametrów) i nie linkować wewnętrznie z UTM. Disallow na /*?* bywa zbyt agresywne.

Googlebot vs inne boty

Możesz mieć osobne reguły User-agent: Googlebot, ale dla strony firmowej zwykle wystarczy *. Nadmierne różnicowanie utrudnia debug.

Co z AI crawlerami (GPTBot itd.)?

Decyzja biznesowa: Allow/Disallow osobno. Nie myl tego z Google Search, to inny ruch i inna polityka treści.

CTA

Potrzebujesz audytu robots.txt, sitemapy i indeksowania Next.js na produkcji?

• Umów audyt crawl / GSC, robots.ts, staging vs prod, DevStudioIT Cloud