Помилка перенаправлення в Search Console та успішна перевірка наживо описують різні спостереження. Перш ніж переписувати контент або змінювати правила, з’ясуйте час кожної перевірки й те, який саме запит завершився невдало.
У повідомленні на форумі Blogger Community від 1 листопада власник сайту описав збережені помилки перенаправлення поряд з успішними поточними перевірками та мобільним переходом на ?m=1. Автор не зміг відтворити петлю й не мав серверних журналів невдалого сканування. Це окреме звернення, а не підтверджений збій платформи чи доказ проблеми кодування.
Один з окремих механізмів, які варто перевірити, — нормалізація адрес. В експерименті від 24 жовтня Марко Федоренко повідомив, що Google повторно отримував перенаправлення, хоча Chrome діставався вмісту. Не змішуйте цей відтворений механізм із невирішеним зверненням щодо Blogger: подібний симптом не доводить спільної причини.
Почніть із часу перевірок, потім дослідіть кодування адреси
Перед порівнянням запишіть дату збереженого сканування, час поточного тесту, точну перевірену адресу й тип пристрою. Успішний запит сьогодні не відтворює невдалого запиту ранішої дати. Збережіть обидва спостереження та шукайте відсутній ланцюжок минулого запиту, замість оголошувати один із результатів помилковим.
За RFC 3986 регістр шістнадцяткових літер у відсотковому кодуванні не змінює значення байтів. Отже, %D1%82 і %d1%82 позначають ті самі байти. Заміна D на d не переводить закодовану кириличну літеру в нижній регістр. Це важливо, коли правило вважає кожну відмінність у сирому рядку підставою для перенаправлення.
Документація Google окремо попереджає, що регістр шляху може розрізняти адреси. Звідси не випливає, що всі частини URL слід безумовно змінювати. Перед нормалізацією визначте, які шляхи застосунок вважає рівнозначними, та зберігайте значення, зміст яких залежить від регістру.
Зафіксуйте відповідь, а не лише вигляд сторінки в браузері
Складіть невеликий набір реальних адрес: звичайний латинський шлях, кириличний, шлях із діакритикою та адресу із закодованим службовим символом, якщо сайт такі використовує. Додайте важливі приклади параметрів запиту. Це запропонована матриця діагностики, а не твердження, що кожен такий URL має помилку.
Для кожної адреси збережіть точний закодований запит, код HTTP, незмінений заголовок Location і кінцеву адресу. Перевірте обидва варіанти регістру шістнадцяткових літер. Перенаправлення, яке змінює лише їх, — сигнал для розслідування, а не самостійний доказ різного вмісту.
Спочатку виконайте запит без автоматичного проходження всіх перенаправлень, потім простежте ланцюжок з обмеженою кількістю переходів. Для перевірки самої сторінки використовуйте GET: успішна відповідь на HEAD ще не доводить, що запит вмісту отримає те саме. Збережіть докази до зміни правила, щоб повторити перевірку після виправлення.
Зіставте журнали сканування з успішним відкриттям у браузері
Шукайте повторні запити тієї самої нормалізованої адреси, які щоразу отримують перенаправлення замість вмісту. Зіставте час і заголовки переходів із контрольним запитом браузера. Перевіряйте справжність робота за оприлюдненим методом Google: назва Googlebot у заголовку запиту сама по собі нічого не підтверджує.
У наведеному експерименті перенаправлення сервера й нормалізація адрес роботом замикали цикл, а браузер проходив до робочого варіанта. На власній інфраструктурі потрібно підтвердити саме таку послідовність. Перевірте разом правила застосунку, проксі та CDN: окремо логічні перетворення можуть по-різному визначати бажаний запис.
Не робіть виняток за назвою робота основним способом виправлення. Він може приховати суперечність і залишити інших клієнтів із тією самою проблемою. Мета — узгоджена політика адрес, яка стабільно повертає потрібну сторінку.
Приймайте виправлення за чіткими умовами
Попросіть розробника визначити нормалізацію окремо для складників URL. Не декодуйте й не кодуйте все без розбору: закодовані роздільники на кшталт %2F, підписані параметри та маршрутизація можуть потребувати особливого оброблення. Універсального безпечного фрагмента коду для всіх систем немає.
До випуску перевірте стабільну успішну кінцеву відповідь для рівнозначних форм кодування, свідомо обрану поведінку для різного регістру самого шляху, збереження параметрів і відсутність повторного циклу. Узгодьте внутрішні посилання, карту сайту та канонічну адресу з обраним варіантом.
Після впровадження повторіть збережені запити й перегляньте наступні відповіді перевіреним роботам. Успішне отримання сторінки — перший результат, але воно не гарантує строку індексації чи повернення позицій. Така послідовність допомагає не сплутати збій отримання з якістю контенту або повільною повторною оцінкою канонічної версії.
Джерела
- Blogspot: GSC redirect error but live test succeeds; mobile 302 to ?m=1
- Як lowercase-редирект ламає індексацію URL з кирилицею та іншими не-ASCII символами
- URL structure best practices for Google Search
- RFC 3986: Uniform Resource Identifier (URI): Generic Syntax
- Redirects and Google Search
- Verify requests from Google crawlers and fetchers
