WordPress SEO: припиніть index bloat — правила noindex, що не вбивають внутрішні посилання

Що таке index bloat насправді (і чому WordPress полегшує його виникнення)

Index bloat — це не просто «Google індексує занадто багато» абстрактно. Це вимірювана невідповідність між:

• URL, які Google може сканувати (виявлені через внутрішні посилання, карти сайту, зовнішні посилання, параметри)
• URL, які Google обирає індексувати (збережені в індексі та потенційно придатні для ранжування)
• URL, які ви мали на увазі (ваш канонічний набір: сторінки, на які ви хочете, щоб приходили користувачі)

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

Пастка: багато з цих сторінок можуть бути корисними для навігації та тематичної кластеризації всередині сайту. Ви хочете, щоб Google розумів цю структуру. Просто ви не хочете, щоб він індексував варіанти з малою цінністю.

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

Операційно — ставтеся до index bloat як до будь-якої іншої проблеми в продакшені: визначте бажаний стан, виміряйте відхилення, а потім впроваджуйте зміни з запобіжними заходами. SEO — це SRE для контенту.

Факти та контекст: як ми опинилися тут

Історичний контекст допомагає, бо поради з WordPress SEO мають властивість фоссилізуватися. Ось кілька конкретних фактів, що досі мають значення:

1. Robots.txt зʼявився в 1994 році як добровільна домовленість; це ніколи не був механізм контролю доступу. Це ввічливий знак, а не замок.
2. Meta robots «noindex» передує сучасним SEO-інструментам і залишається найчистішим способом сказати «можна сканувати, але не індексувати».
3. Canonical-теги стали масовими в 2009 році щоб зменшити хаос дублікатів. Це підказка, а не гарантія, але досі критично важливі.
4. Розмови про crawl budget стали популярні в 2010-х, але практичний висновок старший: не марнуйте зусилля краулера на сміття.
5. Сторінки вкладень WordPress давно є SEO-«пасткою», бо кожен медіа-елемент може стати тонкою сторінкою з майже нульовою цінністю.
6. Архіви тегів створювалися для навігації, а не щоб бути 40-ю «doorway» сторінкою для того ж ключового слова.
7. Фасетна навігація зросла в e‑commerce UX, і з нею зʼявився блоут параметризованих URL; фільтри та плагіни WordPress відтворюють ту ж проблему.
8. «Crawled — currently not indexed» — це не кара; це вибір Google. Ваше завдання — полегшити цей вибір.
9. Сучасний Google може виявляти URL без карт сайту через посилання та фіди; карти сайту — це орієнтир, а не єдина залежність.

Одна цитата, яку варто тримати на столі:

«Надія — не стратегія.» — Gene Kranz

Потрібно не бути хитрим, а бути явним.

Правила руху: noindex, canonical, robots та цінність посилань

Noindex стосується індексації, а не сканування

noindex означає: «Не включати цю сторінку в результати пошуку». Воно не автоматично зупиняє сканування. Google може періодично сканувати таку сторінку, щоб перевіряти сигнали, посилання та директиви.

Disallow стосується сканування, а не індексації (переважно)

Disallow в robots.txt каже: «Не скануйте». Але якщо URL виявлено через зовнішні посилання, Google все одно може індексувати URL без контенту (небажані приклади «indexed, though blocked by robots.txt»). Так утворюються «примарні» записи, які ніколи не консолідують сигнали належним чином.

Canonical консолідує дублікат—коли це правдоподібно

Canonical-тег — це ваша пропозиція основного URL. Він працює найкраще, коли:

• Контент суттєво однаковий.
• Внутрішні посилання підсилюють канонічність.
• Цільовий канонікальний URL доступний і індексується.

Внутрішні посилання все ще можуть вказувати на noindex-сторінки — але робіть це свідомо

Noindex не «вбиває» посилання. Але воно змінює цінність цього URL як цілі. Зазвичай правильний підхід:

• Посилайтеся на індексуємні сторінки, коли це можливо (пости, ключові категорії, що ви хочете ранжувати).
• Використовуйте noindex для сторінок з малою цінністю, дозволяючи їм існувати для користувачів.
• Не зациклюйтеся на «link juice», наче це рідина, що витікає. Думайте в термінах шляхів сканування та канонічних цілей.

Жарт #1: Crawl budget — як ваш календар зустрічей: якщо ви приймаєте кожне запрошення, будете зайняті і нічого не встигнете.

«Набір індексуємих сторінок» — це продуктове рішення, а не налаштування плагіна

Перед тим як змінювати правила, запишіть, що має бути індексуємим:

• Всі пости? Всі сторінки? Тільки продукти?
• Архіви категорій: так/ні (часто так, але тільки ті, що мають редакторське призначення).
• Архіви тегів: зазвичай ні, якщо тільки ви не використовуєте теги як кураторські хаби.
• Архіви авторів/дат: майже завжди ні для блогів з одним автором або маленьких редакцій.
• Результати пошуку: ні.
• Пагінація: залежить, але зазвичай індексується лише сторінка 1, сторінки 2+ — noindex (або обережна канонізація).

Швидкий план діагностики: швидко знайти справжнє вузьке місце

Коли SEO-команда говорить «index bloat», це може означати три різні операційні збої. Перевірте в такому порядку.

По-перше: це проблема виявлення, дублікації чи якості?

• Проблема виявлення: важливі URL не знайдені/не скануються. Симптоми: ключові сторінки відсутні, карта сайту ігнорується, слабка внутрішня перелінковка.
• Проблема дублювання: забагато варіантів URL для одного контенту. Симптоми: параметри, кілька шляхів, непослідовні canonical.
• Проблема якості: Google бачить багато тонких сторінок. Симптоми: «Crawled — currently not indexed», «Duplicate without user-selected canonical».

По-друге: перевірте директиви та їх конфлікти

Знайдіть суперечності, наприклад:

• noindex сторінки включені в XML-карту сайту
• Disallow блокує сторінки, які ви хочете індексувати
• Canonical вказує на URL, який 301/404 або має noindex
• noindex, поєднаний з nofollow повсюдно (чудовий спосіб зробити Google сліпим)

По-третє: перевірте навантаження краулера (логи), а не свої відчуття

Логи доступу сервера покажуть, на що Googlebot витрачає час: сторінки тегів, пошук, сторінки вкладень або нескінченні параметри. Виправте «гарячі точки» першими.

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

Це завдання, які я насправді виконую при діагностиці index bloat у WordPress в продакшені. Кожне містить: команду, приклад виводу, що це означає і яке рішення приймати далі.

Завдання 1: Порахувати унікальні шаблони URL, на які заходить Googlebot (топ-порушники)

cr0x@server:~$ zcat -f /var/log/nginx/access.log* | awk '$0 ~ /Googlebot/ {print $7}' | sed 's/\?.*$//' | awk -F/ '{print "/"$2"/"}' | sort | uniq -c | sort -nr | head
  18231 /tag/
  12044 /wp-content/
   9312 /page/
   7441 /category/
   5220 /?s=
   4109 /author/

Що це означає: Googlebot витрачає багато часу на архіви тегів, пагінацію, пошук, авторів та навіть статичні ресурси.

Рішення: Пріоритезуйте директиви для /tag/, /?s= і архівів авторів. Також переконайтеся, що статичні ресурси не фігурують у якості сканованих сторінок у картах сайту.

Завдання 2: Виявити інтенсивне сканування з параметрами (можливий фільтровий блоут)

cr0x@server:~$ zcat -f /var/log/nginx/access.log* | awk '$0 ~ /Googlebot/ {print $7}' | grep -E '\?.+=' | sed 's/.*?/?/' | cut -d'&' -f1 | sort | uniq -c | sort -nr | head
   6421 ?replytocom=
   3220 ?utm_source=
   1411 ?amp=
   1207 ?orderby=
    988 ?filter=

Що це означає: Параметри на кшталт replytocom та UTM-теги створюють альтернативні URL. Це класичні прискорювачі index bloat.

Рішення: Нормалізуйте через canonical, правила для параметрів (якщо є), і розгляньте редиректи або видалення конкретних параметрів на краю, якщо це безпечно.

Завдання 3: Перевірити URL-карти сайту проти директив індексації (приклад з curl)

cr0x@server:~$ curl -sS -I https://example.com/post-sitemap.xml | head
HTTP/2 200
content-type: application/xml; charset=UTF-8
cache-control: max-age=300, must-revalidate

Що це означає: Карта сайту доступна. Тепер переконайтеся, що вона містить лише індексуємні URL.

Рішення: Запросіть кілька URL із карти сайту та перевірте, що вони не мають noindex, повертають 200 і мають коректний canonical.

Завдання 4: Перевірити robots meta та canonical сторінки (заголовки + HTML grep)

cr0x@server:~$ curl -sS -D- https://example.com/tag/widgets/ | sed -n '1,25p'
HTTP/2 200
content-type: text/html; charset=UTF-8

cr0x@server:~$ curl -sS https://example.com/tag/widgets/ | grep -iE 'robots|canonical' | head
<meta name="robots" content="noindex,follow">
<link rel="canonical" href="https://example.com/tag/widgets/" />

Що це означає: Сторінка тегу встановлена як noindex,follow. Це часто правильно, якщо теги не мають ранжувального значення, але допомагають навігації.

Рішення: Залишайте follow, щоб внутрішні посилання залишалися відкритими для виявлення. Переконайтеся, що сторінки тегів не включені в карти сайту.

Завдання 5: Підтвердити, що robots.txt не блокує те, що ви хочете індексувати

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

Що це означає: /tag/ заборонено, що перешкоджає скануванню і може залишити URL тегів індексованими без контенту, якщо вони виявлені зовнішньо.

Рішення: Краще дозволити сканування + застосувати noindex для архівів тегів, якщо немає вагомої причини блокувати. Видаліть Disallow: /tag/ і обробляйте через мета-роботс.

Завдання 6: Знайти сторінки вкладень, що повертають 200 (кандидати на тонкий контент)

cr0x@server:~$ wp --path=/var/www/html --allow-root post list --post_type=attachment --post_status=inherit --fields=ID,post_title,post_date --format=table | head
+------+------------------------+------------+
| ID   | post_title             | post_date  |
+------+------------------------+------------+
| 4123 | datasheet-widget-01    | 2023-05-10 |
| 4124 | widget-diagram         | 2023-05-10 |
+------+------------------------+------------+

Що це означає: Вкладення існують і, ймовірно, для них створюються сторінки вкладень, якщо тема/плагіни не перенаправляють їх.

Рішення: Перенаправляйте сторінки вкладень на медіафайл або батьківський пост, або застосуйте noindex для вкладень на всьому сайті.

Завдання 7: Перелік публічних типів постів і таксономій (що може генерувати архіви)

cr0x@server:~$ wp --path=/var/www/html --allow-root eval 'print_r(get_post_types(["public"=>true]));'
Array
(
    [post] => post
    [page] => page
    [attachment] => attachment
    [product] => product
)

cr0x@server:~$ wp --path=/var/www/html --allow-root eval 'print_r(get_taxonomies(["public"=>true]));'
Array
(
    [category] => category
    [post_tag] => post_tag
    [product_cat] => product_cat
    [product_tag] => product_tag
)

Що це означає: У вас є таксономії, що можуть створювати архіви: post_tag, product_tag тощо.

Рішення: Вирішіть, які архіви таксономій мають бути індексуємими. Більшість сайтів потребує лише підмножини (часто категорії/категорії продуктів).

Завдання 8: Виявити майже-дублікати URL (http/https, www/non-www)

cr0x@server:~$ curl -sS -I http://example.com/ | head -n 5
HTTP/1.1 301 Moved Permanently
Location: https://example.com/

cr0x@server:~$ curl -sS -I https://www.example.com/ | head -n 5
HTTP/2 301
location: https://example.com/

Що це означає: Налаштовані редиректи. Добре. Тут дублювання контролюється.

Рішення: Підтвердіть, що всі варіанти консолідуються в один канонічний хост і схему скрізь, включно з картами сайту і canonical-тегами.

Завдання 9: Перевірити невідповідності зі слешем наприкінці (дубльовані шляхи)

cr0x@server:~$ curl -sS -I https://example.com/category/widgets | head -n 6
HTTP/2 301
location: https://example.com/category/widgets/

Що це означає: WordPress нормалізує до версії з trailing slash через редирект.

Рішення: Переконайтеся, що canonical-теги завжди використовують нормалізовану версію, щоб уникнути шуму «duplicate, Google chose different canonical».

Завдання 10: Знайти «тонкі» архіви, рахуючи пости на термін

cr0x@server:~$ wp --path=/var/www/html --allow-root term list post_tag --fields=term_id,name,count --format=csv | awk -F',' 'NR>1 && $3+0<3 {print}' | head
102,blue-widgets,1
141,widget-ideas,2
177,old-campaign,1

Що це означає: Багато тегів мають 1–2 пости. Індексувати такі архіви зазвичай марно і це збільшує bloat.

Рішення: Встановіть для архівів тегів noindex,follow, або куутуйте невелику підмножину «хаб-тегів», а решту — noindex (дещо просунута тактика).

Завдання 11: Підтвердити існування внутрішніх сторінок пошуку і їх індексацію (їх не повинно індексуватися)

cr0x@server:~$ curl -sS -I "https://example.com/?s=widgets" | head -n 12
HTTP/2 200
content-type: text/html; charset=UTF-8

cr0x@server:~$ curl -sS "https://example.com/?s=widgets" | grep -i 'robots' | head
<meta name="robots" content="noindex,follow">

Що це означає: Результати пошуку правильно встановлені як noindex. Якби ні — утворився б нескінченний потік сторінок поганої якості.

Рішення: Залишайте їх noindex,follow. Також уникайте посилань на внутрішні результати пошуку в шаблонах.

Завдання 12: Виявити блоут пагінації (page/2, page/3…)

cr0x@server:~$ zcat -f /var/log/nginx/access.log* | awk '$0 ~ /Googlebot/ {print $7}' | grep -E '/page/[0-9]+/' | sed 's/[0-9]\+/\{n\}/' | sort | uniq -c | sort -nr | head
   8022 /category/{n}/
   2210 /tag/{n}/

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

Рішення: Зазвичай: залишайте сторінку 1 індексуємою, сторінки 2+ — noindex,follow. Переконайтеся, що посилання пагінації доступні для сканування, щоб Google діставався до глибших постів при необхідності.

Завдання 13: Перевірити коди відповідей підозрілих наборів URL (404/soft 404)

cr0x@server:~$ zcat -f /var/log/nginx/access.log* | awk '$9 ~ /404|410/ {print $7}' | head
/tag/obsolete/
/category/typoo/
/wp-content/uploads/2019/ghost.png

Що це означає: Поламані архіви і відсутні медіа створюють витрати на краулінг і шум в індексі.

Рішення: Виправте внутрішні посилання, налаштуйте редиректи там, де потрібно, і повертайте 410 для URL, що справді зникли, коли це доречно.

Завдання 14: Переконатися, що ви не відправляєте noindex на сторінки, які хочете ранжувати

cr0x@server:~$ curl -sS https://example.com/important-landing-page/ | grep -i 'meta name="robots"' -n
24:<meta name="robots" content="noindex,nofollow">

Що це означає: Хтось (налаштування плагіна, перемикач середовища або шаблон) випадково noindexed сторінку з прибутку. Це критично.

Рішення: Негайно видаліть noindex, очистіть кеші, повторно надішліть сторінку на індексацію і проведьте аудит налаштування, яке це спричинило, щоб подібне не повторилось.

Правила noindex, що не вбивають внутрішні посилання (практичний список)

Ось набір правил, які я найчастіше застосовую у WordPress. Вони орієнтовані на редакційні сайти й контент-маркетинг, але логіка широка. Для e‑commerce ви залишаєте більше таксономій індексуємими, але все одно noindex для шкідливих варіантів.

1) Внутрішні результати пошуку: noindex, follow

Робіть: noindex,follow для /?s=query та будь-якого «привабного» шляху пошуку, який ви використовуєте.

Чому: Результати пошуку нескінченні, нестабільні та часто тонкі. Їх легко спамити варіаціями запитів.

Збережіть внутрішні посилання: follow дозволяє Google проходити до реальних постів із цих сторінок, якщо він їх просканує.

2) Архіви тегів: за замовчуванням noindex, follow

Робіть: noindex архіви тегів, якщо ви їх активно не кураторите.

Чому: Теги зазвичай недисципліновані. Люди створюють «blue-widget», «blue-widgets», «bluewidget» і залишають їх з одним постом.

Виняток: Якщо у вас контрольований словник і кожен тег — це справжня хаб-сторінка з унікальним вступним текстом і відбором, індексуйте її. Більшість команд цього не роблять.

3) Архіви авторів: noindex для сайтів з одним автором або маленьких команд

Робіть: noindex архіви авторів, якщо вони не дають унікальної цінності понад «пости від X».

Чому: Вони дублюють списки постів. Також створюють дивні тонкі сторінки для «Admin» або старих обліковок.

Збережіть внутрішні посилання: Можете залишати посилання на профілі авторів для користувачів, але переконайтеся, що архіви noindex.

4) Архіви за датами: майже завжди noindex

Робіть: noindex архіви за датами (місячні/щоденні архіви).

Чому: Дати не тематичні. Вони створюють паралельну систему навігації, марну для пошуку, і породжують багато низькоцінних сторінок.

5) Сторінки вкладень: перенаправляти або суворо noindex

Робіть: одне з наступного:

• 301 редирект сторінок вкладень на батьківський пост (переважно, якщо батьківський пост є), або
• редирект на URL медіафайлу, або
• noindex сторінок вкладень на всьому сайті.

Чому: Сторінки вкладень — це SEO‑еквівалент коридору без дверей.

6) Пагінація: зазвичай індексувати сторінку 1, сторінки 2+

Робіть: застосовуйте noindex,follow на пагінованих архівах за межами сторінки 1 (наприклад, /category/widgets/page/2/).

Чому: Пагіновані сторінки часто просто «ще один список», і index bloat швидко розростається. Але їх треба сканувати, щоб виявляти глибші пости.

Обережно: Якщо сторінка 2 має унікальний контент або категорія велика і сторінка 1 не може її представляти, індексація можлива. Для блогів це рідше; для великих каталогів — частіше.

7) Параметризовані URL: canonicalize і прибирати на джерелі

Робіть:

• Тримайте canonical, що вказує на чистий URL (без трекінгових параметрів).
• Не генеруйте ссылок з UTM-параметрами всередині сайту.
• Для відомих параметрів типу replytocom вимкніть поведінку або налаштуйте редирект.

Чому: Параметри множаться. Google хороший, але не для того, щоб вирішувати ваші математичні задачі.

8) Сторінки фільтрів/фасетів (плагіни): явно визначайте, які фасети індексуються

Якщо у вас WooCommerce або плагін фасетної навігації, потрібно вирішити, які фільтри є реальними посадковими сторінками.

• Індексовані фасети: комбінації з високим наміром, які ви можете підтримувати, зі стабільним контентом і попитом.
• Noindex фасети: усе інше, особливо мультифільтрові перестановки, що створюють мільйони сторінок.

Збережіть внутрішні посилання: Користувачам фільтрувати — гаразд; Google індексувати кожну перестановку — ні. Використовуйте noindex,follow або canonical на батьківську категорію там, де потрібно.

9) Дублікати архівів таксономій по типам постів: консолідуйте

Інколи WordPress створює кілька таксономій, що виглядають ідентично («topics», «tags», «labels»). Якщо два архіви конкурують за той самий намір, оберіть один і noindex або редиректуйте інший.

10) Превʼю, стенди та сторінки з параметрами: блокувати правильно

Робіть: Переконайтеся, що стенди (staging) закриті на рівні сервера (авторизація) і також через robots, і ніколи не включені в карти сайту.

Для превʼю типу ?preview=true: заканунизуйте на публічний URL і уникайте індексації. Ці URL витікають назовні.

Жарт #2: Якщо дозволите індексувати кожен архів тегів, ваша SERP-стратегія стане «надіятися, що алгоритм нас прийме». Це не план; це крик про допомогу.

Що означає «правила noindex, що не вбивають внутрішні посилання»

Це означає, що ви уникаєте nofollow за замовчуванням. Шаблон для сторінок з малою цінністю зазвичай такий:

• noindex,follow для сторінок, що допомагають виявленню, але не повинні ранжуватися.
• 301 редирект для дублікатів і застарілих наборів URL.
• Disallow лише коли сканування контенту активно шкодить (нескінченні простори, приватні області, важкі ендпоїнти) і ви готові прийняти побічні ефекти в індексації.

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

Міні-історія 1: Інцидент через хибні припущення

Компанія була в середині ре-платформиції, але «в середині ре-платформиції» — корпоративною мовою означає «усе горить, просто ввічливо». Їхній блог WordPress сидів за CDN і кешуючим шаром, і хтось помітив, що Googlebot штурмує /?s= URL. Швидке виправлення здавалося очевидним: заблокувати внутрішній пошук у robots.txt.

Вони додали Disallow: /?s= і пішли додому задоволені. Приблизно тиждень було спокійно — обсяг краулінгу впав і панелі стали тихішими. Потім органічний трафік почав повільно знижуватися, як сховище, що щотижня втрачає диск.

Хибне припущення: «Якщо ми блокуємо сканування, це не буде індексовано». Насправді стало гірше. Google вже виявив тисячі пошукових URL через внутрішні та зовнішні посилання. Коли сканування було заблоковано, він не міг повторно зчитати їх, щоб побачити noindex або canonical, і не міг правильно консолідувати сигнали.

Search Console показала суміш «Indexed, though blocked by robots.txt» та канонічної плутанини. Індекс набув забруднень з URL-строками без контенту та низькоякісними фрагментами. Тим часом деякі важливі пости сканувалися менше, бо Googlebot все ще досліджував сміття, але вже без можливості його оцінити.

Виправлення було нудним і точним: прибрати disallow, надати noindex,follow для сторінок пошуку і перестати посилатися на пошукові URL у навігації. Краулінг спочатку зріс, потім нормалізувався. Індекс очищувався кілька тижнів. Урок: не використовуйте robots.txt як мітлу; це радше знак «не входити», але люди все одно можуть записати вашу адресу.

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

Маркетингова команда ентерпрайзу вирішила «спростити SEO», встановивши noindex,nofollow для всіх сторінок тегів, категорій і авторів. Ідея була проста: лише пости повинні ранжуватися, усе інше — шум.

Певною мірою це спрацювало. Index bloat впав. Але разом з тим знизився доступ до старих постів. Сайт мав роки контенту, і основна внутрішня навігація була категорійною. Категорії — це сполучна тканина, що вела краулера і користувачів у глибокі архіви.

З nofollow повсюдно граф сканування порідів. Google почав розглядати частини сайту як ізольовані острови. Багато long-tail постів тихо втратили покази, бо потрапляли рідше, і контекст внутрішніх анкорів слабшав.

Вони відкатили частину змін і прибрали nofollow, залишивши noindex,follow для сторінок малої цінності. Для ключових категорій, які були реальними посадковими сторінками, вони зробили їх індексуємими і додали короткі редакційні вступи. Результат був не гучний, але стабільний: менше сміття в індексі і відновлена сила внутрішньої перелінковки.

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

Видавець запускав WordPress в великому масштабі з кількома кастомними типами постів і купою плагінів. SEO‑команда хотіла агресивно noindex, щоб зменшити «Crawled — currently not indexed». Команда SRE відповіла: «Добре, але ми робимо це через change control». Усі зітхнули, як заведено.

Вони вели простий документ-інвентаризацію: які типи URL існують, які індексуються, які noindex, які редиректяться, а які блокуються. Це не шедевр у вигляді таблиці — просто живий мапа. Кожна пропозиція змін мала вказувати сімейство URL і очікувані наслідки в логах і Search Console.

Також вони робили щотижневу вибірку логів: топ шляхів Googlebot, топ 404 і топ параметризованих URL. Коли оновлення плагіна раптом ввело ?amp=1 варіанти і почало лінкувати їх всередині, проблему помітили за кілька днів, а не місяців.

Ця нудна практика запобігла великому розгрому. Не було потреби в героях. Потрібний був зворотний звʼязок: впровадити, спостерігати, відкоригувати. Та сама дисципліна, що й для регресій в продуктивності сховища — виміряйте до і після і не довіряйте «має бути добре».

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

1) Симптом: «Indexed, though blocked by robots.txt» зростає

Корінь: Ви заборонили сканування URL, які виявляються через посилання, тому Google індексує сам URL без можливості оцінити контент чи директиви.

Виправлення: Приберіть disallow для цього набору URL і використайте noindex на сторінках. Для справді нескінченних просторів розгляньте блокування плюс видалення внутрішніх посилань і повернення 404/410, де доречно.

2) Симптом: Важливі сторінки показують «Duplicate without user-selected canonical»

Корінь: Існують множинні варіанти URL (параметри, trailing slash, http/https, www/non-www, нестандартна пагінація), а canonical неконсистентний або неймовірний.

Виправлення: Нормалізуйте через редиректи, переконайтеся, що canonical вказує на фінальний 200 URL, і перестаньте лінкувати на неканонічні варіанти.

3) Симптом: Сторінки тегів випереджають пости (і конверсії падають)

Корінь: Теги індексовані, тонкі і випадково відповідають широким запитам. Google обирає їх як «найкращу» сторінку, бо інший контент розпорошений або продубльований.

Виправлення: Noindex архіви тегів за замовчуванням; індексуйте лише кураторські хаби. Підсиліть внутрішні посилання на бажані посадкові сторінки.

4) Симптом: Багато «Crawled — currently not indexed» для архівів і пагінації

Корінь: Google сканує їх, але не бачить достатньої унікальної цінності або бачить сигнали дублювання.

Виправлення: Noindex сторінки малої цінності і глибоку пагінацію; додавайте canonical, коли дублювання — основна причина; зменшіть кількість виявних смітних URL.

5) Симптом: Раптове деіндексування після оновлення плагіна

Корінь: SEO‑плагін або тема змінили robots meta глобально або включили прапорець «discourage search engines».

Виправлення: Аудитуйте robots meta в ключових шаблонах, зафіксуйте конфігурацію через перевірки середовища і додайте моніторинг, що curlʼить кілька критичних сторінок на предмет index,follow.

6) Симптом: Сторінки вкладень індексуються з дивними фрагментами

Корінь: Сторінки вкладень тонкі і іноді авто-генеровані без контексту; їх можуть лінкувати з пошуку зображень або внутрішніх переліків медіа.

Виправлення: Перенаправляйте сторінки вкладень на батьківські пости або медіафайли; як запасний варіант — noindex.

7) Симптом: Високий рівень краулінгу, але ранжування не поліпшується

Корінь: Зусилля краулера витрачаються на набори низької цінності: параметри, сторінки тегів, внутрішній пошук і тонкі архіви.

Виправлення: Зменшіть виявність сміття і звузьте набір індексуємого. Потім покращуйте сторінки, які залишаються індексуємими.

Перевірочні списки / покроковий план

Крок 1: Визначте ваш набір індексуємих сторінок (запишіть)

• Індексувати: пости, сторінки, продукти, вибрані категорії/категорії продуктів.
• Noindex: внутрішній пошук, архіви тегів, архіви за датами, більшість архівів авторів, сторінки вкладень, пагінація сторінки 2+ (зазвичай).
• Редирект: дублікати (http→https, www→non-www), сторінки вкладень (переважно), застарілі набори URL.
• Блокувати сканування: адмін, логін, важкі API-ендпоїнти, які ви ніколи не хочете, щоб сканували.

Крок 2: Узгодьте карти сайту з цим набором

• У XML-картах мають бути лише індексуємі URL.
• Видаліть noindex URL із карт сайту через налаштування плагінів.
• Переконайтеся, що URL у картах повертають 200 і є канонічними.

Крок 3: Виправте найбільші множники bloat першими

• Внутрішні сторінки пошуку: ensure noindex,follow.
• Теги: встановити noindex,follow, якщо не кураторите.
• Вкладення: перенаправляти або noindex.
• Параметри: припинити їх генерацію всередині сайту; canonicalize; розглянути нормалізацію на краю для відомого сміття.
• Пагінація: noindex сторінки 2+ (зазвичай).

Крок 4: Перевіряйте через логи і спот-чек

• Щотижня вибірково аналізуйте запити Googlebot і відстежуйте топ сімейств URL.
• Curl декілька репрезентативних сторінок і перевіряйте robots meta + canonical.
• Слідкуйте за новими сімействами URL після оновлень плагінів/тем.

Крок 5: Додайте запобіжні заходи (моніторинг)

• Автоматизуйте перевірки robots meta на 10–20 ключових сторінках.
• Сигналізуйте про сплески параметризованого сканування або 404.
• Тримайте «інвентар директив SEO» поряд з інфраструктурною документацією.

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

Чи варто noindex сторінки категорій?

Зазвичай — ні. Категорії часто представляють реальні теми і можуть бути хорошими посадковими сторінками. Індексувати ті категорії, за які ви готові відповідати контентом; тільки noindex, якщо вони тонкі і дублюють інший контент.

Чи дійсно noindex,follow працює, чи Google ігнорує його?

Він дійсний. Нюанс у тому, що Google іноді трактує nofollow як підказку в певних контекстах, але noindex залишається правильною директивою для «не індексувати цю сторінку».

Що краще: noindex чи canonical для дублікатів?

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

Чи нашкодить noindex сторінкам тегів внутрішнім посиланням?

Якщо ви використовуєте noindex,follow, то шляхи сканування зберігаються. Більший ризик — встановити nofollow всюди або блокувати сканування через robots.txt.

Чи варто забороняти архіви тегів у robots.txt, щоб зекономити crawl budget?

Рідко. Disallow перешкоджає скануванню, що може створити артефакти «indexed but blocked», якщо URL тегів виявлені зовнішньо. Краще дозволити сканування і noindex замість повного блокування.

Скільки часу потрібно, щоб index bloat зменшився після змін?

Очікуйте тижні, а не дні. Google повинен повторно просканувати сторінки, щоб побачити директиви, і очистка індексу не миттєва. Ваші логи покажуть зміну поведінки швидше, ніж індекс.

Чи потрібно видаляти noindexed URL з карт сайту?

Так. Карти сайту — це список «будь ласка, індексуйте це». Включення noindexed URL посилає змішані сигнали і марнує увагу.

Що робити з пагінованими сторінками — канонізувати сторінку 2+ на сторінку 1?

Будьте обережні. Канонізація сторінки 2 на сторінку 1 може приховати глибинні елементи і заплутати Google щодо окремих списків. Безпечніший патерн: noindex,follow на сторінках 2+, з коректними посиланнями пагінації.

Чи можна просто видалити сторінки тегів?

Можна припинити генерувати на них внутрішні посилання і зупинити їх створення, але існуючі URL можуть зберегтися зовні. Noindex і/або 301 редиректи чистіші, ніж уявляти, що їх ніколи не було.

Чи корисно блокувати /wp-json/?

Іноді. Для багатьох сайтів дозволено disallow, якщо він створює зайвий краулінг, але будьте обережні: деякі фронтенд‑фічі і плагіни покладаються на нього. Тестуйте, перш ніж «зачиняти двері».

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

Перестаньте трактувати index bloat як містичне SEO‑прокляття. Це просто неконтрольована поверхня URL. WordPress охоче генеруватиме сторінки до кінця часу; ваше завдання — вирішити, які з них мають значення.

Зробіть це далі, в такому порядку:

1. Інвентаризуйте сімейства URL (пости, сторінки, категорії, теги, автори, дати, вкладення, пошук, параметри, пагінація).
2. Встановіть дефолти: пошук, теги, дати, вкладення → noindex,follow (або редирект вкладень). Категорії індексуйте лише якщо це справжні хаби.
3. Приберіть суперечності: видаліть noindex URL з карт сайту; приберіть Disallow в robots.txt, що створює «indexed but blocked» проблеми.
4. Слідкуйте за логами щотижня, поки мікс краулінгу не стане адекватним (менше параметрів, менше сторінок тегів, менше глибокої пагінації).
5. Додайте запобіжні заходи, щоб оновлення плагіна не могло тихо noindexнути ваші найкращі сторінки знову.

Якщо ви це зробите, отримаєте менший, чистіший індекс і сайт, який легше зрозуміти краулерам. Ось і вся гра: зробіть бажану структуру очевидною та припиніть пропонувати Google буфет залишків.