Як діагностувати технічні проблеми з індексацією

Порядок розбору звіту Page indexing у Search Console: що виправляти першим, як підтвердити причини за допомогою URL Inspection і коли зупинитися.

Діагностуйте проблеми з індексацією, відштовхуючись від потрібних вам сторінок, а не від загальних підсумків звіту. Складіть список важливих URL, з'ясуйте, які з них не проіндексовано і чому, а потім опрацьовуйте причини в порядку серйозності: спершу помилки сервера й доступу, далі випадкові блокування, конфлікти canonical, сторінки, схожі на помилки, і наприкінці сторінки, які Google просто вирішив не індексувати. Підтверджуйте кожне виправлення живим тестом у URL Inspection, перш ніж просити Google перевірити його.

Цей посібник припускає, що вам знайомі статуси, описані в статті Індексація: основи.

Крок 1: складіть список важливих URL

Звіт Page indexing враховує кожен URL, відомий Google, зокрема сторінки з параметрами, старі адреси й сторінки, які ви ніколи не збиралися публікувати. Велике число в розділі "Not indexed" — це нормально, і Google прямо каже, що не кожен URL має бути проіндексований (Page indexing report). Тому почніть зі власного списку:

Сторінки, що приносять трафік: 50–100 найкращих у Performance → Pages за три місяці.
Сторінки, що приносять гроші: сторінки товарів, цін, послуг і локацій, незалежно від трафіку.
Нові сторінки: усе, що опубліковано за останні 90 днів.
Ваші sitemap: вони мають містити саме ті канонічні URL, які ви хочете індексувати. Звіт Page indexing можна відфільтрувати за sitemap, щоб побачити, скільки його URL проіндексовано, а кожен sitemap у звіті Sitemaps має посилання на покриття індексацією його URL.

Крок 2: з'ясуйте, які з них не проіндексовано

Для короткого списку перевіряйте кожен URL у URL Inspection. Для довшого відкрийте звіт Page indexing, відфільтрований за вашим sitemap, пройдіть по кожній причині й подивіться, які з ваших важливих URL є серед її прикладів. Записуйте для кожного URL причину та її джерело. Правило Google: загалом ви можете виправити лише ті проблеми, джерелом яких указано "Website".

Крок 3: опрацьовуйте причини по порядку

Виправляйте причини в такій послідовності. Кожен рівень може приховувати наступний, а перші зачіпають найбільше сторінок одразу.

Порядок	Статус	Що перевірити спочатку	Типове виправлення
1	Server error (5xx)	Логи сервера й статус хостингу на момент сканування Google	Усунути проблеми з потужністю чи збоями; повторні відповіді 5xx також змушують Google сканувати повільніше
2	Redirect error	Повний ланцюжок перенаправлень для URL	Перенаправляти одним кроком на кінцевий URL; прибрати цикли
3	Blocked due to unauthorized request (401), access forbidden (403) або інша помилка 4xx	Сторінки входу, правила брандмауера чи захисту від ботів	Дозволити Googlebot доступ до публічних сторінок
4	URL marked 'noindex'	Мета-тег robots сторінки та її заголовок `X-Robots-Tag`	Прибрати noindex зі сторінок, які мають ранжуватися
5	URL blocked by robots.txt	Правило robots.txt, яке спрацьовує	Прибрати правило для сторінок, які мають скануватися
6	Duplicate, Google chose different canonical than user	Який URL указують ваш тег canonical, перенаправлення, sitemap і внутрішні посилання	Зробити так, щоб усі сигнали вказували на один URL
7	Soft 404	Що показує сторінка, коли її отримує Googlebot	Справжній 404 для відсутніх сторінок; справжній контент для справжніх
8	Crawled - currently not indexed	Чи додає сторінка щось такого, чого немає на ваших інших сторінках і в конкурентів	Покращити її або об'єднати з сильнішою сторінкою
9	Discovered - currently not indexed	Чи веде на неї посилання з якоїсь просканованої сторінки	Додати посилання з просканованих сторінок; на дуже великих сайтах керувати скануванням

Діагностика одного URL за допомогою URL Inspection

Для кожного важливого URL зі списку виконайте однакові п'ять перевірок (URL Inspection tool):

Прочитайте вердикт і причину. "URL is unknown to Google" означає, що Google взагалі не бачив цієї адреси, тож завдання — виявлення: додайте посилання на неї зі сторінок, які Google уже сканує, і внесіть її в sitemap.
Порівняйте canonical. Якщо вибраний Google canonical відрізняється від указаного вами, Google індексує інший URL замість цього. Перш ніж щось змінювати, подивіться на той інший URL.
Перевірте сканування. Зверніть увагу на дату останнього сканування, на те, чи сканував Google як смартфон чи як десктоп, чи було сканування дозволене і чи вдалося отримати сторінку. Одне застереження: коли сканування блокує robots.txt, "Indexing allowed?" завжди показує "так", бо Google не бачить noindex на сторінці, яку не має права отримати.
Запустіть Test live URL. Типовий вигляд описує останню проіндексовану версію, яка може бути застарілою. Живий тест отримує сторінку просто зараз і показує знімок відрендереної сторінки — це найшвидший спосіб помітити контент, який з'являється лише для користувачів, що увійшли в акаунт, або після збою скрипта.
Просіть про індексацію лише після виправлення. Google має добову квоту й зазначає, що повторні запити для того самого URL нічого не пришвидшують (Ask Google to recrawl).

Нотатки щодо складніших статусів

Blocked by robots.txt — це не те саме, що "не потрапить в індекс". robots.txt керує скануванням, а не індексацією; заблокований URL, на який посилаються інші сторінки, усе одно може потрапити в індекс без свого вмісту. Щоб утримати сторінку поза Google, дозвольте сканування й використайте noindex у мета-тегу або в заголовку X-Robots-Tag (Block indexing). Пам'ятайте, що видалення відбувається лише після повторного сканування сторінки Google, а це може тривати чималий час.

Конфлікти canonical зазвичай створюємо самі. Google розглядає перенаправлення та rel="canonical" як сильні сигнали, включення в sitemap як слабкий і віддає перевагу HTTPS (Consolidate duplicate URLs). Типовий конфлікт виглядає так: тег canonical указує один URL, а навігація, sitemap і внутрішні посилання використовують його варіант (з кінцевим слешем чи без, з великими літерами, з параметром відстеження, http://). Узгодьте їх, і конфлікт зазвичай зникає під час наступного сканування.

Soft 404 бувають двох видів. Одні — це справді відсутні сторінки, наприклад шаблон "товар не знайдено", що повертає 200; вони мають повертати 404 або 410. Інші — це справжні сторінки, які Google бачить порожніми, як-от категорія без товарів або сторінка, контент якої завантажується після збою скрипта; їм потрібен контент, який Google може побачити, і це підтвердить знімок із живого тесту.

Crawled - currently not indexed — це оцінка, а не помилка. Google просканував сторінку й вирішив наразі її не зберігати; пізніше її можуть проіндексувати, а можуть і ні. Чесно запитайте себе, що сторінка додає. Типові "мешканці" цього статусу — тонкі варіації інших сторінок, сторінки тегів із двома дописами та статті, що повторюють те, що кажуть десять інших сайтів. Зробіть сторінку помітно кращою чи відмінною або об'єднайте її зі сторінкою, яка вже така.

Discovered - currently not indexed здебільшого стосується посилань. Google знає URL, але ще не сканував його. На більшості сайтів виправлення полягає в тому, щоб додати посилання на сторінку зі сторінок, які Google уже сканує, і залишити її в sitemap. Посібник Google щодо краулінгового бюджету написаний для вужчої групи: сайтів із понад мільйоном сторінок, що змінюються щотижня, або з понад 10 000 сторінок, що змінюються щодня (Managing crawl budget). Якщо це ваш випадок, скоротіть перелік URL: об'єднайте дублікати, заблокуйте сканування URL, які ніколи не мають отримуватися, повертайте 404 або 410 для видалених сторінок і виправте soft 404, які сканують знову і знову.

Крок 4: перевірте виправлення

Коли URL за певною причиною виправлено, відкрийте цю причину у звіті Page indexing і натисніть Validate fix — один раз. Спершу Google перевіряє кілька зразкових сторінок; якщо проблема лишається, перевірка зупиняється. Інакше він повторно перевіряє кожен відомий URL, якого це стосується, і позначає його як такий, що пройшов, або не пройшов перевірку. За словами Google, перевірка зазвичай триває до двох тижнів, а іноді значно довше. Google також може помітити виправлення під час звичайного сканування без запиту на перевірку.

Коли зупинитися

Припиніть переслідувати статус, коли URL за ним вам не потрібні в індексі (параметри, відфільтровані види, результати внутрішнього пошуку, старі перенаправлення) або коли сторінку вже покращено, додано на неї посилання й повторно подано, а Google усе одно відмовляється її індексувати після пари місяців. На цьому етапі корисніше об'єднати сторінку з сильнішою й налаштувати перенаправлення, ніж знову просити про індексацію.

Як допомагає AutoPSEO

AutoPSEO перетворює крок 2 на постійну перевірку. Index Tracker зберігає до 1 800 URL на ваш вибір, щодня повторно перевіряє до 200 із них через URL Inspection API (спершу найстаріша перевірка, у межах ліміту Google в 2 000 перевірок на ресурс на добу) і позначає сторінки, видалені з індексу за останні 30 днів, та сторінки, яких Google не сканував 120 днів. Сповіщення Index flip надходить у Slack, Microsoft Teams або вебхук, коли відстежуваний URL випадає з індексу чи повертається до нього (сповіщення). URL Inspection і Sitemaps працюють просто в застосунку, а проблеми сканування Bing показують такі самі проблеми з боку Bing.

Для нових сторінок IndexNow повідомляє Bing та інші пошукові системи, що його підтримують, про змінені URL; Google не бере участі в IndexNow, тож шляхом до Google лишаються sitemap і внутрішні посилання. Статті з контентного рушія доставляються на ваш власний сайт, який публікує їх і додає на них посилання, як і на будь-яку іншу сторінку; коли ваш сайт оголошує ключ IndexNow, AutoPSEO надсилає в IndexNow пінг для кожної опублікованої чи оновленої адреси на вашому хості та записує, що відповів IndexNow (Доставка).