Карта сайту WordPress не індексується: поширені причини та виправлення

Що насправді означає «карта сайту не індексується»

Коли кажуть «моя карта сайту не індексується», мають на увазі одну з чотирьох речей:

• Google не може отримати карту сайту (мережа, DNS, TLS, автентифікація, robots, WAF, помилки 4xx/5xx, петлі редиректів).
• Google отримує файл, але не може його розпарсити (неправильний content-type, HTML замість XML, пошкоджений XML, проблеми з gzip, надто великі файли, некоректні дати, недійсні URL).
• Google розпарсив, але ігнорує URL (блокування через robots, noindex, невідповідність canonical, soft 404, дублі, низька якість, спам-сигнали).
• Google індексує деякі URL, але не інші (бюджет краулінгу, фасетні URL, слабке внутрішнє перелінкування, тонкий контент, параметричний шум).

Карта сайту не гарантує індексацію. Це підказка. Гарна підказка допомагає відкриттю та пріоритетизації; погана підказка — це просто шум, який понижують у пріоритеті. Ваше завдання — зробити її доступною, парсованою і такою, якій можна довіряти.

Одна операційна реальність: у Search Console «Submitted» або навіть «Success» — це не тест «пройшов/не пройшов». Це статус одного кроку у багатокроковому конвеєрі. Ставтеся до цього як до HTTP 200 від зворотного проксі: приємно, але не доказ, що додаток працює.

Факти та історичний контекст (чому це складніше, ніж здається)

• Карти сайту — відносно нові. Протокол XML Sitemaps зʼявився у 2005 році; до того відкриття базувалося здебільшого на посиланнях і вдачі.
• Пошукові системи трактують карти сайту як підказки, а не команди. Той елемент lastmod, який ви ставите, носить рекомендаційний характер; якщо він виглядає ненадійним, його дискредитують.
• Google давно підтримує індексні файли Sitemap, бо один файл має обмеження (зазвичай 50 000 URL і ~50 МБ незжатого). Великі сайти мають розбивати їх.
• WordPress не мав вбудованої карти сайту до версії 5.5 (2020). До того домінували плагіни — і деякі досі конфліктують з core-поведінкою.
• Robots.txt старший за карти сайту на понад десяток років. Він із середини 1990-х і все ще тихо руйнує сучасне SEO, коли хтось копіює «тимчасову» блокування в продакшн.
• Canonical-теги змінили правила гри. Якщо ваш URL у карті сайту суперечить canonical, Google часто довіряє canonical і ігнорує запис у карті сайту.
• CDN стали стандартною інфраструктурою. Чудово для затримки. Також чудово кешувати невірну річ назавжди, якщо дозволити.
• Помилки під час міграції на HTTPS — вічна проблема. Змішування http/https у картах сайту — одна з найпоширеніших «для людини виглядає нормально» помилок.
• WAF і захист від ботів тепер звичні. Багато «пресетів безпеки» кидають Googlebot виклик через JS/CAPTCHA — і потім дивуються, чому відкриття колапсує.

Швидкий план діагностики (перший/другий/третій)

Перший: підтвердіть, що саме намагається отримати Google

1. В Search Console перевірте точну URL карти сайту, яку ви відправили (http vs https, www vs apex, слеш наприкінці, шлях).
2. Перегляньте статус отримання карти сайту і «Last read». Якщо «Couldn’t fetch», припиніть теорії і почніть робити HTTP-запити.
3. Виберіть один URL із карти сайту, який має індексуватися. Перевірте його у Search Console (URL Inspection) і зауважте: «Crawled as», «Indexing allowed?», «User-declared canonical», «Google-selected canonical».

Другий: відтворіть ззовні за допомогою curl

1. Отримайте карту сайту за допомогою curl з переслідуванням редиректів. Перевірте код статусу, content-type і початок тіла.
2. Переконайтеся, що це XML (або gzipped XML), а не HTML, не сторінка логіну, не кешована сторінка помилки.
3. Валідуйте, що ланцюжок редиректів короткий і стабільний (макс. 1–2 переходи).

Третій: простежте відмову всередині стеку

1. Перевірте журнали сервера на спроби та відповіді Googlebot (коди статусу, байти, user agent, крайня локація якщо за CDN).
2. Перевірте robots.txt, meta robots теги та HTTP-заголовки (X-Robots-Tag).
3. Перевірте конфлікти плагінів (core sitemap vs Yoast/Rank Math) і кешуючі шари, які повертають неправильні варіанти.

Якщо виконати ці три фази в зазначеному порядку, зазвичай вузьке місце знаходиться менше ніж за 20 хвилин. Якщо ви одразу приступаєте до «перевстановлення SEO-плагіна», ви просто перезапускаєте принтер.

Режими відмов, які блокують індексацію карти сайту

1) URL карти сайту «правильний» у вашій голові, але неправильний у реальності

WordPress може показувати кілька кінцевих точок карти сайту залежно від core і плагінів:

• Core: /wp-sitemap.xml (і повʼязані індекси).
• Yoast: /sitemap_index.xml
• Rank Math: /sitemap_index.xml (той самий шлях, інший генератор)

Типова плутанина: ви відправляєте /wp-sitemap.xml, але плагін відключив core і віддає щось інше, або ваш зворотний проксі переписує шлях і повертає 200 HTML-помилку. Google не «зрозуміє» це. Він просто зазнає невдачі або ігнорує.

2) robots.txt блокує саму карту або URL, що в ній перераховані

Блокування отримання карти сайту очевидне. Блокування URL, перерахованих у карті сайту, хитріше: карту можна отримати і розпарсити, але жодні її URL не будуть доступні для сканування.

3) noindex, X-Robots-Tag або заголовок безпеки зачиняють двері

На WordPress-сайтах noindex часто накопичується в трьох місцях:

• Meta-тег у HTML (<meta name="robots" content="noindex">), часто встановлений через опцію «Discourage search engines» або перемикач SEO-плагіна.
• HTTP-заголовок (X-Robots-Tag: noindex), зазвичай налаштовується в nginx/Apache правилах або плагіні безпеки.
• Директиви robots.txt, що забороняють сканування.

4) Невідповідність canonical і дублювання варіантів URL

Якщо ваша карта сайту містить http://example.com/page, але сторінка має canonical на https://www.example.com/page/, Google часто вважає запис у карті сайту менш релевантним. Помножте це на тисячі — карта сайту стає фоновим шумом.

5) Карта сайту повертає HTML (або JSON) замість XML

Це трапляється через кеш, WAF-челенджі, «режим технічного обслуговування» або примусову сторінку логіну. Ваш браузер може відобразити щось схоже на норму; Googlebot бачить інший варіант. Якщо CDN робить варіацію на підставі пристрою чи бота — вітаємо: ви створили split-brain.

6) 200 OK з помилковим тілом (мʼякі відмови)

Операційно найгірший баг — це 200 OK з тілом, яке каже «Error». Так роблять деякі плагіни і теми. Деякі зворотні проксі віддають таке, коли upstream недоступний і віддається застаріла кешована сторінка. Google розпарсить сміття і піде далі.

7) Ланцюги редиректів, петлі і «корисна» нормалізація

Три редиректи — це не стратегія. Довгі ланцюги витрачають бюджет краулінгу і інколи ламають отримання. Петлі редиректів самоочевидні і все ще трапляються, бо хтось «виправив» www→apex і apex→www на різних шарах.

8) Помилки сервера і лімітування запитів

Googlebot ввічливий, але відійде, якщо ви кидаєте 429 або нестабільні 5xx. Якщо отримання карти сайту повертає 503 у пікові періоди, Search Console покаже періодичні помилки отримання. Це означає затримку відкриття, а «затримка відкриття» в перекладі для дирекції — «не індексується».

9) Великі карти сайту і повільна генерація

Динамічна генерація карти сайту може бути вимогливою для WordPress. Якщо генерація /sitemap_index.xml викликає важкі запити до БД і таймаути за проксі, ви отримаєте частковий вивід, обрізаний XML або 504. Розбивка карт допомагає, але кешування і препрегенерація допомагають більше.

10) Погана гігієна lastmod (ерозія довіри)

Якщо кожен URL показує однакову lastmod мітку щодня, Google вчиться, що це не має значення. Якщо ваша карта сайту завжди каже «все змінилося», Google сприйме це як хлопчика, що кричав «деплой».

Парафраз ідеї Вернера Фогельса: «Все ламається весь час; будувати системи, що толерують відмови і швидко відновлюються.» Це стосується і SEO-проводки: будуйте для коректності, спостережуваності та граційного деградування.

Короткий жарт №1: Карта сайту, що «самовіндексується», — як пейджер, який підтверджує власні алерти: приємно, але марно.

Практичні завдання: команди, виводи та рішення (12+)

Ці завдання припускають, що у вас є shell-доступ до хосту, який може дістатися вашого сайту (bastion, CI runner або сам вебсервер). Замініть example.com на ваш домен. Суть не в точній команді; суть — в рішенні, яке ви приймаєте на підставі виводу.

Завдання 1: Отримати карту сайту та перевірити статус, редиректи та content-type

cr0x@server:~$ curl -sSIL -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" https://example.com/sitemap_index.xml
HTTP/2 301
location: https://www.example.com/sitemap_index.xml

HTTP/2 200
content-type: application/xml; charset=UTF-8
cache-control: max-age=300

Що це означає: Один редирект до канонічного хоста, потім 200 з XML content-type. Це здорово.

Рішення: Якщо бачите 403/503/429 — виправляйте edge/WAF/ліміти швидкості першими. Якщо content-type — text/html, шукайте шар, що повертає HTML.

Завдання 2: Підтвердити, що тіло справді XML (не сторінка логіну)

cr0x@server:~$ curl -sS -A "Googlebot" https://www.example.com/sitemap_index.xml | head -n 5


  
    https://www.example.com/post-sitemap.xml

Що це означає: Починається з XML-декларації і вузла sitemapindex. Добре.

Рішення: Якщо бачите HTML (<!doctype html>) або сторінку «Увімкніть кукі», ваш WAF/CDN видає неправильний варіант для ботів.

Завдання 3: Швидка валідація коректності XML

cr0x@server:~$ curl -sS https://www.example.com/post-sitemap.xml | xmllint --noout -
cr0x@server:~$ echo $?
0

Що це означає: Код виходу 0 означає, що XML є коректним за структурою.

Рішення: Нульовий код — добре. Ненульовий — XML зламаний. Виправляйте генерацію (плагін/тему), обрізання (таймаути) або стиснення (подвійний gzip) перед будь-якими іншими кроками.

Завдання 4: Перевірити випадкове noindex у HTTP-заголовках

cr0x@server:~$ curl -sSI https://www.example.com/ | egrep -i "x-robots-tag|location|content-type"
content-type: text/html; charset=UTF-8
x-robots-tag: noindex, nofollow

Що це означає: Увесь сайт отримує noindex на рівні заголовків.

Рішення: Заберіть або звузьте застосування цього заголовка. Якщо він з nginx/Apache — виправте конфіг. Якщо з плагіна безпеки — відключіть цю функцію або додайте виняток.

Завдання 5: Перевірити robots.txt і його вміст (включно з директивою sitemap)

cr0x@server:~$ curl -sS https://www.example.com/robots.txt
User-agent: *
Disallow: /wp-admin/
Disallow: /
Sitemap: https://www.example.com/sitemap_index.xml

Що це означає: Disallow: / блокує все. Директива sitemap цього не переважає.

Рішення: Видаліть глобальний disallow (якщо ви дійсно не хочете сховати сайт). Якщо це staging, не копіюйте robots.txt стейджингу в продакшн.

Завдання 6: Перевірити URL у карті сайту на мішані хости/протоколи і редиректи

cr0x@server:~$ curl -sS https://www.example.com/post-sitemap.xml | grep -Eo "[^<]+" | head
http://example.com/hello-world/
http://example.com/about/
http://example.com/contact/

Що це означає: Карта сайту видає http і апекс-домен, а не ваш канонічний https://www.

Рішення: Виправте налаштування WordPress Site URL/Home URL, налаштування плагінів та хардкодні фільтри. Після цього повторно надішліть карту сайту. Не покладайтеся на редиректи як «виправлення».

Завдання 7: Вибірково перевірити URL із карти сайту — canonical і meta robots

cr0x@server:~$ curl -sS https://www.example.com/hello-world/ | egrep -i "

Що це означає: Canonical збігається з URL і сторінка індексується.

Рішення: Якщо canonical вказує кудись ще або meta robots містить noindex, виправте шаблон/правила SEO-плагіна. Якщо це навмисно (архіви тегів, внутрішній пошук) — видаліть такі URL з карти сайту.

Завдання 8: Виявити, чи карта сайту стискається gzip або подвійно стиснута

cr0x@server:~$ curl -sSI -H "Accept-Encoding: gzip" https://www.example.com/post-sitemap.xml | egrep -i "content-encoding|content-type"
content-type: application/xml; charset=UTF-8
content-encoding: gzip

Що це означає: Gzip увімкнено; це ок.

Рішення: Якщо бачите gzip, але тіло насправді не gzip (або gzip всередині gzip), виправте налаштування стиснення сервера/CDN. Googlebot терплячий, але не телепат.

Завдання 9: Підтвердити, що карта сайту не за паролем і не за IP-allowlist

cr0x@server:~$ curl -sSIL https://www.example.com/sitemap_index.xml | head
HTTP/2 401
www-authenticate: Basic realm="Restricted"

Що це означає: Карта сайту захищена автентифікацією. Google не може її отримати.

Рішення: Зніміть автентифікацію з публічних шляхів або захищайте лише адміністрування. Якщо це staging — не відправляйте його карту сайту.

Завдання 10: Перевірити nginx access логи на запити Googlebot до карт сайту та коди статусу

cr0x@server:~$ sudo grep -E "Googlebot|sitemap" /var/log/nginx/access.log | tail -n 5
203.0.113.10 - - [27/Dec/2025:10:21:12 +0000] "GET /sitemap_index.xml HTTP/2.0" 200 1249 "-" "Googlebot/2.1"
203.0.113.10 - - [27/Dec/2025:10:21:13 +0000] "GET /post-sitemap.xml HTTP/2.0" 503 182 "-" "Googlebot/2.1"

Що це означає: Індексний файл отримано, але дочірня карта інколи повертає 503.

Рішення: Виправте стабільність origin для дочірніх карт (таймаути, насичення PHP-FPM, база даних). Google вважатиме ненадійні хости за недовіри.

Завдання 11: Шукати насичення PHP-FPM, що спричиняє 504/503

cr0x@server:~$ sudo tail -n 8 /var/log/php8.2-fpm.log
[27-Dec-2025 10:21:13] WARNING: [pool www] server reached pm.max_children setting (20), consider raising it
[27-Dec-2025 10:21:13] WARNING: [pool www] child 1942 said into stderr: "script_filename = /var/www/html/index.php"

Що це означає: Ваш PHP-пул вичерпався. Генерація карти сайту може додатково навантажити його під час сканування.

Рішення: Додайте кешування для кінцевих точок карти сайту, збільшіть потужність обережно або зменшіть важкі запити до БД. Не просто підвищуйте pm.max_children без обчислення памʼяті.

Завдання 12: Перевірити налаштування «Discourage search engines» через wp-cli

cr0x@server:~$ cd /var/www/html
cr0x@server:~$ wp option get blog_public
0

Що це означає: WordPress налаштовано на відлякування пошукових систем (часто встановлює noindex через плагіни/теми або впливає на вивід robots).

Рішення: Встановіть його в 1 у продакшні, потім перевірте реальні заголовки/meta/robots.

cr0x@server:~$ wp option update blog_public 1
Success: Updated 'blog_public' option.

Завдання 13: Підтвердити, який генератор карти сайту активний (конфлікти плагінів)

cr0x@server:~$ wp plugin list --status=active
+--------------------+--------+-----------+---------+
| name               | status | update    | version |
+--------------------+--------+-----------+---------+
| wordpress-seo      | active | none      | 22.5    |
| rank-math          | active | available | 1.0.225 |
| wp-super-cache     | active | none      | 1.12.3  |
+--------------------+--------+-----------+---------+

Що це означає: Два SEO-плагіни активні. Ось як зʼявляються дуелюючі canonical, дуелюючі карти сайту і дуелюючі звинувачення.

Рішення: Оберіть один SEO-плагін. Вимкніть інший. Потім ще раз підтвердіть кінцеву точку карти сайту і поведінку canonical.

Завдання 14: Перевірити, що CDN не кешує карту сайту неправильно

cr0x@server:~$ curl -sSI https://www.example.com/sitemap_index.xml | egrep -i "cf-cache-status|age|via|x-cache"
cf-cache-status: HIT
age: 86400

Що це означає: CDN повертає день стару кешовану карту сайту. Це може бути нормально — але не якщо вона закешувала сторінку помилки або застарілий вміст після міграції.

Рішення: Пропустіть/очистьте кеш для URL карти сайту, встановіть адекватний TTL і подумайте про винятки «Cache Everything». Карти сайту повинні кешуватися, але не постійно бути неправильними.

Завдання 15: Перевірити вплив продуктивності БД при динамічній генерації карт

cr0x@server:~$ mysql -NBe "SHOW FULL PROCESSLIST" | head
12345	root	localhost	wp	Query	2	Sending data	SELECT ID, post_title FROM wp_posts WHERE post_status='publish' ORDER BY post_modified DESC LIMIT 50000

Що це означає: Генерація карти сайту може виконувати важкі запити. На спільних БД це конкурує з обслуговуванням сторінок.

Рішення: Кешуйте вивід карти сайту, препрегенеруйте або оптимізуйте запити/індекси. Якщо кінцева точка повільна, Googlebot про це дізнається і рідше її відвідуватиме.

Три корпоративні міні-історії з польових боїв

Міні-історія 1: Інцидент через неправильне припущення

Вони перенесли маркетинговий сайт на WordPress за CDN і новим WAF. Команда припустила: «Якщо головна сторінка відкривається в браузері, то Google може її сканувати.» Це припущення годилося б у музей поруч із Netscape.

Search Console почав показувати помилки отримання карти сайту. SEO-менеджер ескалював, платформа відмахнулась, і всі вказували пальцем одне на одного. URL карти сайту повертав 200 і виглядав нормально — у звичайному браузері. Коли ж його отримував бот-юзерагент, WAF віддавав сторінку з JavaScript-челенджем. Все ще 200. Все ще «нормально» для тих, хто не парсить XML.

Виправлення було дивовижно простим: правило WAF дозволило перевіреним краулерам отримувати кінцеві точки карти сайту і ключові шляхи без челенджів. Справжня робота полягала в дисципліні: curl-тести в CI, синтетична перевірка «bot fetch» і політика, що «контролі безпеки мають бути спостережуваними».

Після зміни індексація відновилася поступово впродовж кількох днів. Ця затримка спричинила більше драм, ніж сам інцидент. Але саме так — сканування є консистентним із відстрочкою й має backoff. Якщо ваша організація не може чекати — не ламайте відкриття.

Міні-історія 2: Оптимізація, що дала зворотній ефект

Інша компанія вирішила прискорити все, кешуючи контент на краю. Правило CDN: кешувати HTML 24 години, ігнорувати query-рядки і «оптимізувати» контент. Сайт став швидким. Дашборди зазеленіли. Усі святкували й пішли додому.

Потім запустили нову лінійку продуктів і оновили сотні сторінок. Внутрішньо сторінки були оновлені. Ззовні Googlebot бачив старий контент. Карта сайту оновилась на origin, але CDN продовжував віддавати застарілий індексний файл з устарілими lastmod і інколи кешовану 503 відповідь, яку origin віддав під час деплою.

Search Console показував дивні речі: «Sitemap can be read, but has errors», а URL залишалися «Discovered – currently not indexed» довше, ніж зазвичай. Команда намагалася «примусити індексацію», повторно відсилаючи карту сайту, що не допомогло, бо запит все одно потрапляв на застарілий обʼєкт на краю.

Виправлення: виділити явну поведінку кешування для кінцевих точок карт сайту (короткий TTL, без трансформацій, cache-key включає хост, очищення при деплої). Також припинили авто-оновлення lastmod для незмінних сторінок, бо це навчило Google ігнорувати мітки. Сайт став трохи гіршим у Lighthouse. Індексація стала значно передбачуванішою. Вибирайте свої пріоритети.

Міні-історія 3: Нудна, але правильна практика, що врятувала день

У великому підприємстві WordPress був лише одним із багатьох платформ. Була нудна політика: для кожного публічного хоста мав бути стандартний «runbook про crawlability» і щотижневий автоматичний чек, що валідовує robots, карту сайту і кілька канонічних сторінок. Без винятків. Без героїв.

Одної пʼятниці зміна DNS для стейджингу витекла в продакшн: апекс-домен почав редиректити на хост обслуговування для частини користувачів. Браузери іноді працювали завдяки кешованому HSTS і щасливим шляхам. Googlebot же йшов редиректами, наче платили за кожен хоп, і врешті опинявся на 404-сторінці з кодом 200 (бо таке теж буває).

Автоматичний чек зловив це за хвилини. Не тому, що він був розумним — а тому, що був нудним: curl fetch, валідація XML, перевірка canonical, алерт при не-XML content-type. Розробник на чергуванні мав чіткий diff змін і відкатив DNS до стану до інциденту, поки pipeline краулінгу ще не відкотився.

Нічого драматичного не сталося. І в цьому суть. Найкращий SEO-аутейдж — це той, що не перетворюється на нараду.

Короткий жарт №2: Єдина річ більш оптимістична за карту сайту — це план проєкту з пунктом «індексація: 2 дні».

Типові помилки: симптом → корінь проблеми → виправлення

«Couldn’t fetch» у Search Console

• Симптом: Search Console показує «Couldn’t fetch» або «Fetch failed».
• Корінь проблеми: 401/403 від WAF, автентифікація, геоблоки або IP-allowlist; 5xx через нестабільний origin; DNS/TLS проблеми.
• Виправлення: Відтворіть за допомогою curl з Googlebot UA; перевірте access логи; додайте в біллист бот-трафік для кінцевих точок карти сайту; стабілізуйте origin і приберіть автентифікацію з публічних шляхів.

«Карта сайту — HTML» або «Неправильний формат»

• Симптом: Search Console скаржиться на формат або повідомляє про помилки парсингу.
• Корінь проблеми: CDN/WAF повертає HTML-челендж, сторінку логіну або сторінку технічного обслуговування; PHP таймаут обрізає XML.
• Виправлення: Забезпечте content-type: application/xml; обійдіть трансформації для маршрутів карти сайту; додайте кеш для генерації карти сайту; збільшіть upstream timeouts лише разом з оптимізацією повільних сторін.

«Success», але URL не індексуються

• Симптом: Статус карти сайту — «Success», але coverage показує «Discovered – currently not indexed» або «Crawled – currently not indexed».
• Корінь проблеми: URL блокують robots/noindex; невідповідність canonical; тонкий/дублікатний контент; слабке внутрішнє перелінкування; надто багато низькоцінних URL.
• Виправлення: Виберіть репрезентативні URL і інспектуйте їх; приберіть noindex і виправте canonical; очистіть карти сайту, залишивши лише цінні для індексації URL; покращіть внутрішні посилання для важливих сторінок.

Працюють лише деякі карти (індексний файл ок, дочірні карти падають)

• Симптом: Індексний файл доступний, але дочірні карти інколи падають або повертають 5xx.
• Корінь проблеми: Важка динамічна генерація; насичення PHP-FPM; повільна БД; неконсистентний кеш; ліміти швидкості.
• Виправлення: Кешуйте вивід дочірніх карт; препрегенеруйте; розбивайте по типам записів/даті; налаштуйте PHP-FPM і БД; додайте моніторинг кінцевих точок карти сайту.

Індексація впала після HTTPS або міграції домену

• Симптом: URL зникають; Search Console показує дублі і проблеми з альтернативними canonical.
• Корінь проблеми: Змішані http/https і www/apex варіанти у карті сайту; старі canonical; петлі редиректів; неконсистентна нормалізація хостів між CDN і origin.
• Виправлення: Визначте один канонічний хост/протокол; оновіть налаштування WordPress; регенеруйте карти сайту; тримайте редиректи простими і на одному шарі; аудитуйте canonical-теги.

Масові «Excluded by ‘noindex’ tag»

• Симптом: Coverage показує багато виключених через noindex.
• Корінь проблеми: Увімкнено «Discourage search engines»; шаблони SEO-плагіна виставляють noindex для постів; HTTP X-Robots-Tag встановлено широко.
• Виправлення: Підтвердіть через curl; виправте на найвужчому відповідальному шарі; потім видаліть noindex з карти сайту (не включайте в карту сайту те, що відмовляєтеся індексувати).

«Submitted URL seems to be a Soft 404»

• Симптом: Google вважає сторінки soft 404, хоча вони повертають 200.
• Корінь проблеми: Тонкий контент, шаблон «результатів немає», приховування контенту від ботів або сторінки помилок, що повертають 200.
• Виправлення: Повертайте коректні 404/410 для відсутнього контенту; уникайте клоакінгу; покращіть реальний контент і внутрішнє перелінкування; видаліть сміттєві URL з карти сайту.

Контрольні списки / покроковий план

Покроково: зробіть карту сайту доступною та такою, якій довіряють

1. Оберіть один генератор карти сайту. Core або один плагін. Вимкніть інші. Конфлікти — це не «резервування».
2. Закріпіть канонічний хост/протокол. Вирішіть щодо https і або www, або апексу. Примусіть це одним правилом редиректу на edge або origin (не дозволяйте їм воювати).
3. Валідуйте поведінку кінцевої точки карти сайту. 200, XML content-type, адекватне кешування, без трансформацій, без автентифікації, без челенджів.
4. Перевірте дочірні карти сайту. Випадково оберіть 5 дочірніх карт і 10 URL. Якщо ви не вибираєте, ви покладаєтеся на найоптимістичнішу частину стеку.
5. Видаліть низькоцінні URL з карти сайту. Ніяких архівів тегів, якщо вони не мають цінного контенту. Ні внутрішнього пошуку. Ні пагінації сміття. Ні параметрних варіантів.
6. Виправте невідповідності robots/noindex/canonical. Не включайте URL, які ви забороняєте, ставите в noindex або канонізуєте кудись ще. Це марнує час.
7. Зробіть генерацію карти сайту дешевою. Кешуйте вивід. Якщо вона динамічна і дорога — препрегенеруйте або використайте object caching. Трафік Googlebot не має бути вашим тестом навантаження.
8. Повторно надішліть карту сайту після реальних змін. Не як ритуал. Повторна відправка має сенс, коли змінились кінцева точка, хост, протокол або ви прибрали блокування.
9. Моніторьте її як API. Синтетичні перевірки, що валідують content-type і парсованість XML, кращі, ніж чекати, поки Search Console образиться.

Операційний чекліст: перед тим як звинувачувати Google

• Чи можете ви отримати карту сайту з клієнта, що не браузер?
• Чи повертає вона XML і чи валідна?
• Чи є 4xx/5xx/429 у логах для шляхів карти сайту?
• Чи robots.txt дозволяє те, що ви хочете індексувати?
• Чи вибрані URL повертають сигнали індексації (немає noindex, canonical співпадає)?
• Чи ваш CDN кешує або трансформує відповіді карт сайту?
• Чи ви нещодавно не деплоїли, не мігрували, не змінювали DNS або не ввімкнули режим WAF?

Мінімальна «здубована» гігієна карти сайту

• Використовуйте абсолютні URL у <loc>, лише канонічний хост.
• Розбивайте карти сайту коли великі; використовуйте індекс карт сайту.
• Встановлюйте lastmod тільки коли контент дійсно змінюється.
• Не включайте URL, що в noindex, редиректяться або блокуються robots.
• Подавайте з коректним content-type і стабільним кешуванням.

Питання та відповіді

Чому Search Console каже «Success», але мої сторінки все ще не індексуються?

Бо «Success» означає, що Google отримав і розпарсив карту сайту. Індексація залежить від самих URL: robots/noindex, вибір canonical, оцінка якості, дублікати і планування краулінгу.

Яку карту сайту подавати для WordPress: wp-sitemap.xml чи sitemap_index.xml?

Подавайте ту, яку фактично віддає ваш сайт як авторитетну індексну карту. Якщо ви використовуєте SEO-плагін, який надає /sitemap_index.xml, відправте саме її. Якщо ви покладаєтесь на core — відправте /wp-sitemap.xml. Не надсилайте обидві, якщо вам не подобається подвійний сигнал.

Чи може CDN зламати індексацію карти сайту?

Абсолютно. CDN може кешувати застарілі карти, трансформувати контент або подавати челенджі ботам. Зробіть кінцеві точки карти сайту передбачуваними: короткий TTL, без переписування HTML, без бот-челенджів і очищення при деплої/міграції.

Чи потрібна директива Sitemap у robots.txt?

Це допомагає, але не обовʼязково, якщо ви надіслали карту сайту в Search Console. Все одно варто додати — інші краулери її використовують, а також це корисний покажчик при дебагу.

Чи включати архіви категорій/тегів у карту сайту?

Тільки якщо ці сторінки дійсно цінні як посадкові сторінки з унікальним контентом. Якщо вони тонкі, дублюють або автогенеровані — виставте noindex і приберіть їх з карти сайту.

Як часто має оновлюватися моя карта сайту?

Коли відбуваються осмислені зміни контенту. Уникайте оновлення lastmod для кожного URL при кожному запиті; це привчає пошукові системи ігнорувати мітки. Кешуйте карту сайту і регенеруйте під час публікації/оновлення.

Чи «Discourage search engines» у WordPress повністю блокує індексацію?

Може, залежно від теми/плагінів і як вони це реалізують. Сприймайте це як тривожний сигнал у продакшні. Перевірте реальні сигнали через curl: meta robots і будь-які X-Robots-Tag заголовки.

Який найшвидший спосіб перевірити, чи Googlebot блокується?

Перевірте access логи на наявність запитів з Googlebot UA до шляхів карти сайту і ключових сторінок, потім уточніть коди статусу і обʼєм байтів. Поєднайте це з curl з Googlebot UA поза вашою мережею.

Чи важливі редиректи в карті сайту?

Так. Кілька редиректів не вбʼють все, але карти сайту повинні містити фінальні канонічні URL. Якщо все редиректиться, ви марнуєте бюджет краулінгу і показуєте погану гігієну.

Моя карта сайту має понад 50 000 URL. Це проблема?

Це проблема, якщо це один файл. Розбивайте і використовуйте індекс карт сайту. Більш важливо: переконайтеся, що ці URL заслуговують індексації. Великі карти сайту часто ховають проблему якості, а не технічну.

Висновок: наступні кроки, що дійсно дають результат

Якщо ви хочете, щоб карта сайту WordPress сприяла індексації, припиніть сприймати її як магічний SEO-артефакт і почніть ставитися до неї як до кінцевої точки API з чіткими споживачами.

1. Прогнайте швидкий план діагностики: підтвердіть точну URL, зробіть curl як Googlebot, потім перевірте логи і директиви.
2. Виправте доступність: 200 OK, коректний XML, без автентифікації, без WAF-челенджів, без циркусу редиректів.
3. Виправте сигнали довіри: відповідність canonical, узгодженість noindex/robots і включайте лише ті URL, які ви справді хочете індексувати.
4. Зробіть це операційним: моніторинг кінцевих точок карти сайту, інтелектуальне кешування і перевірка краулінгу після кожної міграції або зміни CDN/безпеки.

Зробіть це — і «не індексується» перестане бути тривожною загадкою і перетвориться на звичайний інцидент з коренем проблеми і завданням на виправлення. Як і має бути.