Jak usunąć, zablokować wp-sitemap z WordPressa?

Wszystkie kompilacje WordPressa od 5.5 w górę mają narzuconą z automatu sitemapę „wordpressową” i w zasadzie – zanim się o tym dowiedziałem, szczerze się ucieszyłem, że WordPress po nota bene 17 latach doczekał się natywnej sitemapy, tyle tylko, że jest totalnie niekonfigurowalna bez dodatkowych wtyczek. A przecież nie po to WordPress ma natywną sitemapę, żeby teraz instalować wtyczkę, która ją skonfiguruje, dlatego dziś wyjaśnię, jak się tej wp-sitemap’y pozbyć teraz i w przyszłości, w jakich okolicznościach istnieje ryzyko, że Was WordPress generuje 2 różne sitemapy i jak rozwiązać ten problem.

Zacznę jeszcze od tego, że jeśli Wasza strona firmowa nie ma zbyt dużej liczby widoków, to sam fakt posiadania lub nie posiadania sitemapy w tym kontekście ma niską kaloryczność na pozycjonowanie w wynikach organicznych. Ale jeśli mówimy już o blogu z setką wpisów, małym sklepie, albo serwisie contentowym, to sitemapa może ratować nieco crawling bota, szczególnie jeśli wybrane zasoby, np. produkty, artykuły są niewystarczająco dobrze podlinkowane wewnętrznie w architekturze informacji. Zachęcam w tym miejscu, żebyście korzystali ze Screaming Froga – przy dużym site możecie wygenerować nim prostą wizualizację architektury informacji, z której dowiecie się, że np. do ostatniej setki produktów w Waszym sklepie prowadzi tylko 1 link wewnętrzny w 1 widoku i tym widokiem jest 34 strona paginacji kategorii.

Ale – wracając do tematu – rzecz wydarzyła się taka, że WP od kompilacji 5.5 ma swoją, natywną sitemapę i jeśli macie wyjątkowe pecha, to istnieje ryzyko, że Wasz WP ma 2 równoległe sitemapy. Jedną Waszą, dotychczasową o adresacji najczęściej nazwadomeny.pl/sitemap.xml, a także drugą, natywną, wordpressową o adresacji nazwadomeny.pl/wp-sitemap.xml.

No i ten wp-sitemap.xml jest najbardziej prymitywną sitemapą, jaką można wygerować. Poza tym, że nie posiada instrukcji na temat częstotliwości zmian w contencie konkretnych zasobów, priorytetów, dat utworzenia zasobów, to zawiera cały śmietnik, jaki masz w swoim WordPressie. Jako, że z panelu jej nie obsłużycie, nie macie możliwości wykluczenia z niej widoków z osadzonym w kodzie meta tagiem noindex, nie wykluczycie z niej archiwów, odnośników do profili użytkowników i tagów (inna sprawa, że nie wiem, dlaczego z tagów na WordPressie mielibyście korzystać, ale jeśli macie wątpliwości, to w międzyczasie zachęcam do obejrzenia materiału: Tagi a pozycjonowanie).

I zasadniczo – spalanie crawl budgetu na sitemapie, która linkuje do podstron z noindexem, podstron typu thin content jest po prostu kiepską praktyką.

I teraz niezależnie od tego, czy w Waszych WordPressach istnieją równolegle 2 sitemapy, czy też macie tylko tą pierwszą, albo tylko tą drugą, to warto, abyście uszczelnili swoje WordPressy i wykluczyli z niego tą wp-sitemap.

I domyślne rozwiązanie WordPress’a dotyczące generowania mapy strony możecie zablokowane jedną linią takiego kodu:

add_filter('wp_sitemaps_enabled', '__return_false');

Kod ten osadzacie w pliku functions.php w głównym folderze Waszego motywu.

Zasadniczo – tak, jak wcześniej wsp omniałem, musielibyście mieć pecha, żeby Wasz WP w 2021 r. miał dwie równolegle istniejące sitemapy, bo to co musiałoby się wydarzyć, to musielibyście mieć świeżego WP, czyli 5.5 w górę i zarazem starą kompilację wtyczki All in One SEO albo Yoast, które zakładam, że obsługują w Waszych WP sitemapy, bo te wtyczki też już od którychś kompilacji same wykluczają istnienie podwójnej adresacji sitemap, więc teoretycznie tego wpisu robić nie musicie, ale pamiętajcie, że to są tylko wtyczki, dlatego ręczne zablokowanie WP w generowaniutej wp-sitemapy na poziomie pliku daje większe poczucie bezpieczeństwa.