Jak stworzyć mapę strony XML w WordPressie i innych CMS?

Co powinno trafić do mapy, a co nie

Mapa witryny ma podpowiadać wyszukiwarce adresy, które chcesz mieć w indeksie. Dlatego trafiają do niej wyłącznie strony, które spełniają jednocześnie trzy warunki: zwracają kod 200, są kanoniczne, czyli canonical wskazuje na nie same, i nie mają tagu noindex. Wszystko inne usuwam:

• adresy przekierowane i zwracające błędy 404 lub 410,
• strony z canonicalem wskazującym inny adres, np. warianty produktów czy wersje z parametrami,
• strony z noindex oraz zablokowane w pliku robots.txt,
• wyniki wewnętrznej wyszukiwarki, kombinacje filtrów i strony techniczne, takie jak koszyk czy panel klienta.

Mapa pełna takich adresów nie tylko nie pomaga, ale osłabia jej wiarygodność jako źródła informacji dla Google. W dużych serwisach ma to bezpośredni wpływ na crawl budget.

Jakie znaczniki mają znaczenie

Każdy wpis w mapie to adres w znaczniku <loc>, a opcjonalnie data ostatniej modyfikacji w <lastmod>:

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://twojadomena.pl/blog/przykladowy-wpis</loc>
    <lastmod>2026-10-20</lastmod>
  </url>
</urlset>

Z dodatkowych znaczników praktyczne znaczenie ma tylko lastmod, i to pod warunkiem, że jest prawdziwy. Google korzysta z niego, gdy data zmienia się wyłącznie przy rzeczywistej zmianie treści. Jeśli system ustawia dzisiejszą datę przy każdym wygenerowaniu mapy, informacja staje się bezużyteczna. Znaczniki changefreq i priority Google ignoruje, więc ich nie dodaję.

Limit to 50 000 adresów lub 50 MB na plik. Większe serwisy dzielę na kilka map i łączę je w indeksie map. Nawet w mniejszych projektach dzielę mapę na sekcje, np. strony, blog i produkty, bo wtedy w Search Console widać osobno, ile adresów z każdej sekcji jest zindeksowanych.

Mapa strony w WordPressie

WordPress od wersji 5.5 sam generuje podstawową mapę pod adresem /wp-sitemap.xml. Jeśli na stronie działa wtyczka SEO, np. Yoast SEO lub Rank Math, przejmuje ona to zadanie i udostępnia własny indeks map, zwykle pod adresem /sitemap_index.xml, wyłączając mapę wbudowaną. Po instalacji wtyczki sprawdzam trzy rzeczy:

1. Czy działa tylko jedna mapa. Dwie mapy z różnych źródeł, np. z WordPressa i z wtyczki, to częsty powód zamieszania w Search Console.
2. Czy w mapie nie ma typów treści, które nie powinny być w indeksie, np. stron tagów, archiwów autorów, załączników czy szablonów z page buildera. Wyłączam je w ustawieniach wtyczki.
3. Czy strony oznaczone jako noindex rzeczywiście znikają z mapy.

Przy wyborze wtyczki odpowiedzialnej za mapę kieruję się tymi samymi zasadami co przy innych wtyczkach do WordPressa: jedna wtyczka do jednego zadania i żadnych dublujących się funkcji.

Mapa strony w innych CMS-ach i sklepach

Niezależnie od systemu zasada jest ta sama: mapa ma powstawać automatycznie z aktualnych danych. Ręcznie przygotowany plik, który ktoś raz wgrał na serwer, po kilku miesiącach zawiera już nieistniejące adresy, a nowe strony w nim nie występują.

Mapa strony we własnym kodzie

W projektach bez CMS-a albo przy architekturze headless generuję mapę w kodzie aplikacji, z tych samych danych, z których powstają strony. Tak działa też ta strona: mapa witryny jest generowana w PHP z tych samych plików, z których powstają wpisy i słownik pojęć. Wpisy z przyszłą datą publikacji trafiają do mapy dopiero w dniu publikacji, a lastmod pochodzi z daty modyfikacji wpisu, więc zmienia się tylko wtedy, gdy rzeczywiście coś zaktualizuję. Uproszczona wersja takiego mechanizmu wygląda tak:

<?php
header('Content-Type: application/xml; charset=UTF-8');
$posts = json_decode(file_get_contents(__DIR__ . '/blog.json'), true);
$today = new DateTime('today');

echo '<?xml version="1.0" encoding="UTF-8"?>';
echo '<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">';
foreach ($posts as $p) {
    $pub = DateTime::createFromFormat('d.m.Y', $p['date']);
    if (!$pub || $pub > $today) { continue; }   // wpisy zaplanowane pomijamy
    $mod = !empty($p['modified_date'])
        ? DateTime::createFromFormat('d.m.Y', $p['modified_date'])
        : $pub;
    echo '<url><loc>https://twojadomena.pl/blog/' . htmlspecialchars($p['slug'], ENT_XML1) . '</loc>'
       . '<lastmod>' . $mod->format('Y-m-d') . '</lastmod></url>';
}
echo '</urlset>';

Przy dużej liczbie adresów warto wynik zapisywać w pamięci podręcznej albo generować plik okresowo, zamiast budować go od zera przy każdym żądaniu. Generatory online czy eksport mapy ze Screaming Froga sprawdzają się tylko przy małych, rzadko zmienianych stronach.

Zgłoszenie mapy i sprawdzanie jej poprawności

Mapę zgłaszam w Google Search Console w raporcie Mapy witryn, podając adres indeksu map albo pojedynczej mapy. Dodatkowo wpisuję jej adres w pliku robots.txt w linii Sitemap:, z której korzystają także inne wyszukiwarki. Jeśli używam indeksu map, wystarczy zgłosić właśnie jego, a Google sam odczyta mapy podrzędne.

Samo zgłoszenie to dopiero początek. Regularnie sprawdzam:

• status mapy w Search Console i liczbę wykrytych adresów,
• raport stron, filtrowany według mapy witryny, żeby zobaczyć, ile adresów z mapy jest zindeksowanych i dlaczego reszta nie jest,
• crawl w Screaming Frogu z włączonymi mapami witryn, który pokazuje adresy w mapie niedające się zindeksować, adresy z crawla nieobecne w mapie i strony osierocone, do których prowadzi tylko mapa.

Mapa witryny jest jednym z pierwszych plików, które sprawdzam podczas każdego audytu technicznego SEO, bo jej stan dobrze pokazuje, czy serwis jest utrzymywany w porządku, czy tylko działa.