Dlaczego sitemap i robots.txt są ważne?
Sitemap.xml informuje wyszukiwarki o wszystkich stronach w serwisie — ich lokalizacji, dacie ostatniej modyfikacji i opcjonalnych wskazówkach, a plik Robots.txt kontroluje, które ścieżki crawlery mogą swobodnie odwiedzać. Choć oba pliki, nie gwarantują indeksacji ani jej blokady, są fundamentem technicznego SEO.
Next.js App Router oferuje natywne API (bez zewnętrznych biblioktek) do generowania obu plików.
Natywna sitemap w App Router
Statyczna sitemap
Najprostszym sposobem jest eksport tablicy obiektów z pliku sitemap.ts:
Next.js generuje /sitemap.xml automatycznie.
Pułapka: lastModified: new Date() dla stron statycznych. Użycie new Date() (aktualny czas buildu) dla stron, które rzadko się zmieniają, spowoduje, że przy każdym deployu Google zobaczy nową datę modyfikacji. Może to zmylić crawlera i zmarnować crawl budget. Dla stron statycznych używaj konkretnej daty lub pomijaj pole lastModified całkowicie. Dla treści z bazy danych pobieraj faktyczne pole updatedAt z rekordu.
changeFrequency i priority Google oficjalnie deklaruje, że oba pola traktuje tylko jako wskazówki i w praktyce je ignoruje. Z kolei inne wyszukiwarki (Bing, Yandex) mogą je uwzględniać, więc warto je wypełniać, ale nie skupiaj się na ich optymalizacji, kosztem innych działań SEO.
Dynamiczna sitemap — wpisy z CMS/bazy
Wielojęzyczna sitemap z hreflang
Natywne API obsługuje pole alternates, służy do deklarowania wersji językowych strony, co Google wymaga przy implementacji hreflang:
Google wymaga, żeby każda wersja językowa wskazywała na pozostałe wersje w alternates (symetrycznie), jednostronne deklaracje hreflang są ignorowane.
Wiele sitemaps — dla dużych serwisów
Sitemap ma limit 50 000 URL-ów lub 50 MB (nieskompresowany), dla dużych serwisów — generuj wiele sitemaps z indeksem:
Next.js automatycznie generuje indeks sitemaps: /sitemap.xml → zawiera linki do /sitemap/0.xml, /sitemap/1.xml itd.
Natywny robots.txt
Wynikowy /robots.txt:
next-sitemap — kiedy natywne API nie wystarczy
Biblioteka next-sitemap oferuje dodatkowe funkcje, czyli automatyczne wykrywanie statycznie wygenerowanych stron po buildzie, wielojęzyczne sitemaps z hreflang, server-side sitemap regeneration i konfigurację per-ścieżka.
Natywne API vs next-sitemap — co wybrać?
| Funkcja | Natywne API | next-sitemap |
|---|---|---|
| Automatyczne wykrywanie stron | Nie | Tak (po buildzie) |
| Dynamiczne strony z DB | Tak (ręczne) | Tak (server sitemap) |
| Hreflang / alternates | Tak (pole alternates) | Tak (automatyczne) |
| Wielki serwis (> 50K stron) | Tak (generateSitemaps) | Tak (sitemapSize) |
| Konfiguracja per-ścieżka | Ręczna (w kodzie) | transform function |
| Dodatkowe zależności | Zero | 1 pakiet |
| Koszt utrzymania | Minimalny (część frameworka) | Wyższy (zależność do aktualizacji) |
Werdykt: Dla większości projektów, zwłaszcza tych z przewidywalną strukturą, natywne API Next.js jest w zupełności wystarczające, prostsze i nie wprowadza dodatkowych zależności. Sięgnij po next-sitemap tylko w wyjątkowych sytuacjach, gdy masz bardzo duży, nietypowy serwis, gdzie automatyczne wykrywanie stron i zaawansowane transformacje oszczędzą Ci mnóstwa pracy manualnej.
Weryfikacja w Google Search Console
Po wdrożeniu sitemap i robots.txt:
- Otwórz Google Search Console → Sitemaps
- Dodaj URL sitemap:
https://strivelab.pl/sitemap.xml - Sprawdź status — Google pokaże liczbę wykrytych i zaindeksowanych stron
- Monitoruj zakładkę „Strony" — szukaj błędów indeksowania
Podsumowanie
Dzięki natywnemu API w Next.js App Router, automatyczne generowanie plików sitemap.xml i robots.txt sprowadza się do kilku linii kodu w TypeScript. Wbudowane narzędzia (sitemap.ts, robots.ts) pokrywają 90% typowych scenariuszy bez potrzeby instalowania zewnętrznych bibliotek. Nawet przy ogromnych serwisach z dynamiczną treścią, funkcja generateSitemaps elegancko radzi sobie z automatycznym podziałem mapy na mniejsze pliki.
Cała filozofia sprowadza się do kilku dobrych praktyk. Pamiętaj, aby zawsze używać faktycznej daty modyfikacji w lastModified, poza tym unikaj używania new Date() dla stron statycznych, co zapobiega marnowaniu budżetu na ponowne crawlowanie niezmienionych treści. W robots.txt zablokuj ścieżki, które nie powinny być publiczne (np. /admin, /api), a po wdrożeniu koniecznie sprawdź status sitemapy w Google Search Console.
Najczęściej zadawane pytania
Czy sitemap jest wymagana do indeksowania?
Nie, Google może indeksować strony bez sitemap (przez linki wewnętrzne i zewnętrzne), ale sitemap przyspiesza odkrywanie nowych stron i informuje o zmianach. Jest to szczególnie w dużych serwisach lub przy braku zewnętrznych linków.
Jak często Google czyta sitemap?
Google sprawdza sitemap okresowo i nie ma jakiejś z góry ustalonej częstotliwości. Możesz wymusić ponowne sprawdzenie w Search Console (przycisk „Prześlij ponownie") i czekać na wynik.
Czy changefreq i priority wpływają na pozycje w Google?
Nie, Google wskazuje, że oba pola traktuje tylko jako wskazówki i w praktyce je ignoruje. Warto je wypełniać dla innych wyszukiwarek (Bing, Yandex), które mogą je respektować, ale nie mają żadnego wpływu na wyniki w Google - oczywiście, jeśli przyjmujemy, że wszystko co twierdzi Google odpowiada rzeczywistości.
Czy blokowanie botów AI w robots.txt jest skuteczne?
Działa dla botów, które respektują plik robots.txt. Zarówno GPTBot (OpenAI), jak i Google-Extended (Gemini) deklarują, że to robią. Jednak robots.txt to tylko prośba, a nie techniczna zapora — złośliwy lub źle skonfigurowany crawler może zignorować te dyrektywy. Jest to jednak obecnie standardowa metoda komunikowania swoich preferencji botom AI.
