Search Console показує «Сторінка з переадресацією»: яку URL-адресу перевірити?

Ви переносите сторінку послуги з /old-service на /services/design. Згодом Search Console показує стару адресу в розділі «Сторінка з переадресацією». Нова сторінка відкривається у браузері. Чи потрібно також домагатися індексації старої адреси?

Зазвичай корисніше запитати, чи веде стара адреса на сторінку, яку ви справді хочете показати людям. Google описує цей статус як неканонічну URL-адресу, що переадресовує на іншу сторінку. Початкова URL-адреса за такого статусу не індексується; цільова може бути проіндексована або ні. Інший пункт звіту, «Помилка переадресації», описує проблему, з якою Google зіткнувся під час переходу, наприклад цикл або надто довгий ланцюжок.

Наведений приклад є ілюстративним і не походить із перевірки сайту клієнта. Ось як перевірити одну важливу URL-адресу, перш ніж змінювати переадресації на всьому сайті.

Запишіть початкову адресу та бажану ціль

У Search Console відкрийте звіт про індексування сторінок, виберіть «Сторінка з переадресацією» та одну URL-адресу. Скопіюйте повну адресу: http або https, ім'я хоста, шлях, кінцеву похилу риску та параметри запиту, якщо вони є. Якщо звіт показує дату останнього сканування Google, запишіть і її.

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

Сам факт появи URL-адреси у звіті не доводить, що ціль проіндексовано або що переадресація погіршила ваші позиції. Він також не показує, яке налаштування створило переадресацію.

Перейдіть за адресою без входу в обліковий запис

Відкрийте початкову URL-адресу в приватному вікні браузера та запишіть кінцеву адресу в адресному рядку. Чи відкривається очікувана сторінка з потрібним вмістом? Якщо переадресація веде до входу, неправильної мови, не пов'язаної послуги або помилки, зафіксуйте, що сталося і коли. Приватний браузер показує шлях для цього відвідувача; Googlebot може отримати іншу відповідь, наприклад якщо правило залежить від user agent.

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

/old-service → /services → /services/design

Цей ланцюжок лише приклад. Якщо певний крок повертає на попередню адресу або вказує на недійсну чи порожню ціль, дослідіть його. Google відносить до «Помилок переадресації» цикли, надто довгі ланцюжки, недійсні або порожні URL-адреси та адреси, які зрештою стають надто довгими. Пункт «Сторінка з переадресацією» автоматично не означає жодної з цих помилок.

На платформі переадресації можуть налаштовуватися в її панелі, плагіні, вебсервері або іншому шарі, наприклад CDN. Правила різних шарів можуть конфліктувати, тому перед зміною простежте шлях і перевірте, до якого шару належить кожне правило. Не вставляйте приватні URL-адреси, токени доступу чи дані клієнтів у публічний сервіс налагодження.

Окремо перевірте цільову адресу

В інструменті перевірки URL перегляньте проіндексований результат для джерела та дату сканування. Потім перевірте бажану ціль як окрему URL-адресу. Звіт про джерело не визначає стан індексації цілі. Якщо ціль розташована за межами ресурсу, який ви можете перевірити, переконайтеся в її публічній доступності та за потреби запитайте власника. Ви можете не мати доступу до її стану індексації в Search Console; відсутність результату перевірки не доводить, що сторінку не проіндексовано.

За словами Google, перевірка активної сторінки переходить за переадресацією та перевіряє кінцеву URL-адресу, але не показує, що перехід відбувся, або яку кінцеву адресу перевірено. Тому вона допомагає перевірити поточний доступ, але не замінює перевірки шляху від джерела до цілі. Результат перевірки активної сторінки також не гарантує індексації й не передбачає канонічну URL-адресу, яку вибере Google. Порівняйте його із записаними Google даними індексу та їхніми датами, розглядаючи їх як окремі спостереження.

Якщо ціль не проіндексована, перевірте зазначену для неї причину. Наприклад, навмисний noindex на цільовій сторінці — це інше питання, ніж правильна переадресація з початкової адреси. Усуньте причину індексації самої цілі. Видалення робочої переадресації лише для очищення запису про джерело не розв'язує проблему noindex на цілі.

Вирішіть, залишити чи виправити

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

Якщо важлива сторінка несподівано переадресовує на неправильну ціль, знайдіть і виправте відповідне правило. Сторінка товару, яка веде на не пов'язану головну сторінку, відрізняється від старої URL-адреси, що веде на свою заміну. Якщо для видаленої сторінки немає відповідної заміни, відповідь 404 Not Found або 410 Gone може бути доречною. Переадресацію не пов'язаних видалених сторінок на головну можуть трактувати як soft 404.

Для постійного перенесення рекомендації Google трактують постійні переадресації, як-от 301 і 308, як сигнали, що ціль має бути канонічною. Тимчасові переадресації, як-от 302 і 307, мають іншу семантику. Google ставить серверні переадресації першими серед методів, які найімовірніше правильно інтерпретує. Обирайте залежно від того, чи планується перенесення надовго; вибрана Google канонічна URL-адреса може відрізнятися від вашої бажаної.

Спрямуйте власні посилання на потрібну сторінку

Якщо поточна карта сайту або внутрішнє посилання досі використовує стару URL-адресу, за потреби оновіть її на бажану ціль. Наприклад, після перенесення /old-service на /services/design підконтрольне вам навігаційне посилання може вести безпосередньо на /services/design. Збережіть переадресацію для старих посилань, які ви не можете оновити. Не видаляйте її лише тому, що змінили власну навігацію.

Таке впорядкування дає відвідувачам прямий шлях і чіткіше повідомляє Google бажану адресу. Воно не обіцяє індексації та не вимагає замінювати кожне старе посилання в інтернеті. Search Console може повідомляти про URL-адреси, знайдені не у вашій поточній карті сайту.

Перевірте один шлях повторно та запишіть результат

Після виправлення знову перевірте шлях від джерела до цілі та повторно перевірте ціль. Занотуйте джерело, кінцеву URL-адресу, помічені відповіді або кроки переадресації, внесену зміну та дату. Якщо ви виправили реальну проблему, Search Console пропонує перевірку виправлення, щоб Google міг переглянути її знову. Перевірка не гарантує індексації цілі або оновлення звіту в конкретний день.

Для окремого огляду головної сторінки SEO-перевірка сайту SEOHabit після реєстрації пропонує першу перевірку, обмежену головною сторінкою. Для цієї першої перевірки підтвердження права власності на сайт не потрібне, але для постійних перевірок воно потрібне. Інструмент не може пояснити, чому Google вибрав певну ціль переадресації; для цього використовуйте Search Console та фактичний шлях переадресації.

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

Джерела: звіт Google про індексування сторінок (https://support.google.com/webmasters/answer/7440203), довідка інструмента перевірки URL (https://support.google.com/webmasters/answer/9012289) та настанови щодо переадресацій (https://developers.google.com/search/docs/crawling-indexing/301-redirects).