Jak przygotować mapę witryny XML dla dużego katalogu branżowego

Mapa witryny dużego katalogu branżowego nie może być prostym eksportem wszystkich adresów zapisanych w bazie. Taki plik szybko zapełnia się profilami bez treści, wynikami filtrowania, duplikatami lokalizacji i stronami, których robot wyszukiwarki i tak nie powinien indeksować. Efekt jest przewidywalny: Google pobiera sitemapę, ale znaczną część zgłoszonych adresów odrzuca albo przez wiele tygodni nie podejmuje próby ich indeksowania.

Dobra mapa witryny XML pełni inną funkcję. Ma wskazywać kanoniczne, dostępne i wartościowe adresy, informować o rzeczywistych zmianach oraz pozwalać szybko ustalić, która część katalogu powoduje problemy. Przy kilkuset tysiącach wizytówek firm podział plików, sposób aktualizowania dat i kontrola kodów odpowiedzi HTTP mają większe znaczenie niż samo wygenerowanie poprawnego XML-a.

Najpierw ustal, które adresy naprawdę powinny znaleźć się w mapie

Do sitemapy należy dodawać wyłącznie adresy, które mają być widoczne w wynikach wyszukiwania. To brzmi banalnie, ale właśnie na tym etapie duże katalogi popełniają najwięcej błędów. Generator pobiera wszystkie rekordy ze statusem „aktywny”, chociaż część profili jest pusta, zablokowana, zduplikowana albo dostępna pod kilkoma wariantami URL.

Przed wygenerowaniem pliku trzeba zbudować jednoznaczny warunek kwalifikujący stronę do mapy. Profil firmy powinien spełniać co najmniej następujące wymagania:

• zwracać kod HTTP 200 bez przekierowania;
• nie zawierać dyrektywy noindex;
• nie być zablokowany w pliku robots.txt;
• wskazywać sam na siebie w znaczniku canonical;
• zawierać nazwę firmy, kategorię i dane pozwalające odróżnić ją od innych wpisów;
• być dostępny z wewnętrznego linkowania, a nie wyłącznie z sitemapy;
• nie być kopią profilu utworzoną przez zmianę kolejności parametrów lub wariantu sluga.

Jeżeli wizytówka zawiera tylko nazwę, miasto i automatycznie wygenerowane zdanie, jej obecność w XML-u nie poprawi jakości indeksowania. Sitemap nie naprawia słabej treści. Może jedynie ułatwić robotowi dotarcie do strony, którą później i tak oceni według tych samych kryteriów co pozostałe dokumenty.

Szczególnej kontroli wymagają strony kategorii i lokalizacji. Adresy takie jak /hydraulicy/warszawa/ mogą być wartościowe, jeżeli pokazują realną listę firm, mają unikalny opis, poprawną paginację oraz są dostępne z hierarchii kategorii. Nie należy natomiast automatycznie dodawać każdej kombinacji branży, dzielnicy, województwa i filtra. Przy 800 kategoriach, 380 powiatach i kilku dodatkowych parametrach baza może utworzyć miliony adresów, z których większość pokaże jedną firmę albo pustą listę.

Praktyczna zasada jest prosta: strona filtrowania powinna wejść do sitemapy dopiero wtedy, gdy ma stały popyt, wystarczającą liczbę ofert i własną wartość informacyjną. W katalogu lokalnym sensownym progiem startowym bywa na przykład pięć aktywnych wizytówek, ale nie jest to uniwersalna norma. Dla niszowej branży trzy dobrze opisane firmy mogą wystarczyć, natomiast w kategorii „mechanik samochodowy Warszawa” nawet kilkadziesiąt wpisów nie pomoże, jeżeli lista jest pełna duplikatów.

Z mapy trzeba bezwzględnie usunąć:

• adresy z kodami 3xx, 4xx i 5xx;
• wewnętrzne wyniki wyszukiwania;
• strony sortowania i filtrowania oparte na parametrach;
• profile oczekujące na publikację;
• wygasłe oferty bez wartościowego zamiennika;
• strony z canonicalem prowadzącym do innego adresu;
• duplikaty utworzone przez wersję z ukośnikiem i bez ukośnika, wielkie litery albo różne protokoły.

Najbardziej irytujący problem pojawia się wtedy, gdy logika sitemapy różni się od logiki serwisu. Profil zostaje usunięty z katalogu, lecz nadal widnieje w XML-u przez kilka tygodni, ponieważ mapa jest generowana z kopii bazy aktualizowanej raz w miesiącu. Przy dużym katalogu generator powinien korzystać z tego samego źródła statusów co aplikacja, a usunięcia i zmiany indeksowalności muszą trafiać do kolejnego przebiegu bez ręcznej ingerencji.

Podziel pliki według typu treści i tempa zmian

Jeden plik sitemapy może zawierać maksymalnie 50 000 adresów URL i mieć nie więcej niż 50 MB po rozpakowaniu. To wartości graniczne, a nie rekomendowany rozmiar roboczy. W praktyce nie ma dobrego powodu, aby każdą mapę wypełniać dokładnie do 50 000 pozycji.

Dla dużego katalogu bezpieczniejszy jest podział na pliki zawierające od 10 000 do 40 000 adresów. Mniejszy plik szybciej się generuje, łatwiej go pobrać, a awaria jednego segmentu nie blokuje całej struktury. Różnica w liczbie plików jest mało istotna. Znacznie ważniejsza jest możliwość szybkiego wskazania, czy problem dotyczy profili firm, kategorii, miast czy artykułów poradnikowych.

Czytelny układ może wyglądać tak:

• sitemap-firmy-001.xml.gz;
• sitemap-firmy-002.xml.gz;
• sitemap-kategorie.xml.gz;
• sitemap-lokalizacje.xml.gz;
• sitemap-artykuly.xml.gz;
• sitemap-index.xml.

Główny plik sitemap-index.xml nie zawiera adresów stron. Wskazuje pliki podrzędne. Sam indeks może zawierać do 50 000 odwołań do sitemap, dlatego limit ten w praktyce nie będzie ograniczeniem nawet dla katalogu liczącego dziesiątki milionów profili.

Podział wyłącznie według kolejnych identyfikatorów rekordów jest łatwy do wdrożenia, lecz słaby diagnostycznie. Gdy raport pokaże spadek liczby zaindeksowanych adresów w sitemap-017.xml, nadal nie wiadomo, jaki typ stron ucierpiał. Lepszy jest podział najpierw według rodzaju dokumentu, a dopiero później na kolejne paczki.

Przy bardzo dużej liczbie profili można zastosować dodatkowy poziom organizacji, na przykład:

• rodzaj strony;
• województwo;
• przedział identyfikatorów;
• miesiąc publikacji lub aktualizacji.

Nie należy jednak rozdrabniać struktury bez potrzeby. Kilka tysięcy plików po 100 adresów komplikuje monitoring, zwiększa liczbę żądań do serwera i utrudnia analizę raportów. Dla katalogu mającego 600 000 indeksowalnych wizytówek rozsądniejszym punktem wyjścia będzie 15–30 plików niż 6000 mikromap.

Pliki warto kompresować za pomocą gzip. Zmniejsza to transfer i obciążenie sieciowe, choć limit 50 MB nadal dotyczy wersji po rozpakowaniu. Serwer musi też poprawnie obsługiwać nagłówki HTTP. Mapa zwracająca kod 200, ale podająca stronę błędu HTML zamiast XML-a, jest szczególnie zdradliwa: monitoring dostępności uzna żądanie za udane, natomiast wyszukiwarka odrzuci zawartość.

Każdy adres w pliku powinien być pełny i używać docelowego wariantu protokołu oraz hosta, na przykład:

https://example.pl/firma/nazwa-firmy/

Nie należy mieszać wersji http, https, www i bez www. Sitemap powinna zawierać dokładnie taki URL, jaki jest używany jako canonical i zwracany użytkownikom bez przekierowania.

Znaczniki changefreq i priority nie powinny sterować architekturą mapy. W dużych serwisach są często wypełniane automatycznie tą samą wartością, więc nie przekazują użytecznej informacji. Znacznie ważniejszy jest poprawny lastmod, ale tylko wtedy, gdy oznacza rzeczywistą istotną zmianę strony.

Aktualizuj lastmod na podstawie treści, a nie każdego zapisu w bazie

Data lastmod powinna zmienić się wtedy, gdy zmieniła się zawartość istotna z punktu widzenia użytkownika lub wyszukiwarki. Może to być nowy opis przedsiębiorstwa, zmiana adresu, aktualizacja usług, dodanie istotnej sekcji, publikacja nowych zdjęć albo korekta danych kontaktowych.

Nie powinny jej zmieniać:

• logowanie właściciela profilu;
• aktualizacja liczby wyświetleń;
• zapis wewnętrznej notatki moderatora;
• odświeżenie cache;
• zmiana kolejności rekordów technicznych;
• ponowne zapisanie identycznych danych;
• aktualizacja pola updated_at, która nie wpływa na treść strony.

To jeden z najbardziej kosztownych błędów w dużych katalogach. Jeżeli każda nocna synchronizacja ustawia nową datę modyfikacji dla 500 000 profili, wszystkie adresy wyglądają jak świeżo zmienione. Robot przestaje otrzymywać użyteczny sygnał, a serwis generuje niepotrzebny ruch. Fałszywy lastmod jest gorszy niż brak tego znacznika.

Najpewniejsze rozwiązanie to oddzielenie technicznego pola updated_at od pola opisującego istotną zmianę publicznej treści, na przykład content_modified_at. Druga data powinna być aktualizowana tylko po modyfikacji pól widocznych na stronie. W bardziej rozbudowanym systemie można obliczać skrót zawartości indeksowalnej i zmieniać datę dopiero wtedy, gdy skrót rzeczywiście się różni.

Nie ma potrzeby przebudowywania całego zestawu plików po zmianie jednego profilu. Dla katalogu o dużym ruchu lepiej zastosować generowanie przyrostowe:

1. System zapisuje identyfikatory stron, których treść lub status indeksowalności uległy zmianie.
2. Zadanie cykliczne ustala, do którego pliku należy każdy adres.
3. Przebudowywane są tylko zmienione segmenty.
4. Po zakończeniu generator zapisuje plik tymczasowy.
5. Dopiero po walidacji następuje atomowa podmiana starego pliku.

Plik tymczasowy jest ważny. Bez niego robot może pobrać sitemapę w trakcie zapisu i otrzymać niepełny XML. Najprostszy bezpieczny mechanizm polega na utworzeniu sitemap-firmy-012.xml.tmp, sprawdzeniu składni oraz liczby adresów, a następnie zmianie nazwy na docelową.

Częstotliwość generowania trzeba dopasować do tempa zmian:

• profile aktualizowane przez użytkowników przez cały dzień: co 1–6 godzin;
• stabilne strony kategorii: raz na dobę;
• artykuły publikowane sporadycznie: po publikacji i każdej istotnej korekcie;
• archiwalne profile bez zmian: przebudowa tylko po zmianie statusu lub treści.

Generowanie wszystkich map co pięć minut zwykle nie ma sensu. Obciąża bazę, zapisuje duże pliki i nie gwarantuje szybszego indeksowania. Sitemap jest wskazówką dla wyszukiwarki, a nie poleceniem natychmiastowego odwiedzenia adresu.

Po wdrożeniu należy porównywać cztery liczby: liczbę rekordów kwalifikujących się do indeksacji, liczbę unikalnych adresów wygenerowanych w sitemapach, liczbę adresów odczytanych przez wyszukiwarkę oraz liczbę stron faktycznie indeksowanych. Pierwsze dwie wartości powinny być prawie identyczne. Duża różnica między zgłoszeniem a indeksacją wymaga już analizy jakości stron, canonicali, odpowiedzi serwera, duplikacji i linkowania wewnętrznego.

Samo zgłoszenie mapy nie gwarantuje indeksacji. To ważne szczególnie w katalogach firm, w których tysiące wpisów mają podobną konstrukcję. Wyszukiwarka może poprawnie pobrać wszystkie pliki, a mimo to pominąć profile uznane za zbyt ubogie, powtarzalne albo nieistotne. Rozwiązaniem nie jest wtedy częstsze wysyłanie XML-a, lecz poprawa danych, eliminacja duplikatów i wzmocnienie wewnętrznej struktury kategorii.

FAQ

Czy każda firma z bazy powinna znaleźć się w sitemapie?
Nie. Do mapy powinny trafiać wyłącznie opublikowane, kanoniczne i indeksowalne profile zwracające kod HTTP 200. Rekord administracyjny nie musi być wartościową stroną dla użytkownika.

Ile adresów najlepiej umieszczać w jednym pliku?
Techniczny limit wynosi 50 000 adresów, ale w dużym katalogu praktycznym zakresem jest zwykle 10 000–40 000. Mniejsze segmenty łatwiej generować, kontrolować i diagnozować.

Czy usunięty profil należy pozostawić w mapie, żeby Google szybciej zobaczył kod 404 lub 410?
Nie. Po usunięciu strony trzeba usunąć ją również z sitemapy. Kod 404 albo 410 wyszukiwarka wykryje podczas kolejnego odwiedzenia adresu lub przez linki, które nadal do niego prowadzą.

Czy sitemapę należy zgłaszać ponownie po każdej aktualizacji?
Nie. Wystarczy utrzymywać stały adres pliku i aktualizować jego zawartość. Ponowne ręczne zgłaszanie po każdej zmianie nie przyspiesza automatycznie indeksowania.

Czy mapa XML zastępuje linkowanie wewnętrzne?
Nie. Ważne profile i kategorie powinny być dostępne przez zwykłe linki HTML. Strona znana wyłącznie z sitemapy może zostać odkryta, ale brak powiązań z resztą serwisu osłabia jej kontekst i znaczenie.

Czy trzeba dodawać mapę do pliku robots.txt?
Jest to użyteczne i pozwala robotom łatwo znaleźć jej adres. Wystarczy umieścić pełny adres indeksu, na przykład Sitemap: https://example.pl/sitemap-index.xml.

Jak często kontrolować poprawność plików?
Automatyczna kontrola powinna działać po każdym wygenerowaniu. Raz dziennie warto dodatkowo sprawdzać kod HTTP, składnię XML, liczbę URL-i, duplikaty, przekierowania oraz obecność adresów z noindex.

Pierwszy krok nie polega na wyborze generatora ani zgłoszeniu pliku w Google Search Console. Najpierw wykonaj eksport wszystkich adresów planowanych do sitemapy i sprawdź ich kody HTTP, canonicale oraz dyrektywy indeksowania. W pierwszej kolejności usuń URL-e przekierowujące, niekanoniczne i oznaczone jako noindex. Dopiero z oczyszczonego zbioru buduj podzielone mapy XML — inaczej szybciej zgłosisz wyszukiwarce błędy, a nie wartościowe strony.

Więcej informacji na: katalog NAP – https://biznap.pl