Адреса сторінки — рядок, який пишеш один раз і потім живеш із ним роками. 19 серпня 2026 року ми переписали 76 таких рядків за один захід, причому в більшості випадків різниця між старим і новим написанням — одна-дві літери. 24 вересня ми відкрили Search Console, щоб побачити, чим це обійшлося. Нижче обидві частини історії: рішення, яке ми досі вважаємо правильним, і помилка, через яку старі адреси майже шість днів відповідали 404.
Звідки взялися дві транслітерації в одному шляху
Спершу контекст, бо перейменуванню передувала інша зміна. До 18 серпня сторінки послуг під /ru і /en жили під українськими адресами: англійська сторінка, наприклад, відкривалась за /en/rozrobka/sajty/lending. Колонка з мовними адресами в базі була, адмінка в неї писала, але роутер її не читав — 183 сторінки з 257 мали заповнене поле, яке нікуди не вело. 18 серпня кожна мова отримала власну адресу, а стара українська переїжджала постійним редиректом. Ця подія окрема, і в цій статті ми її не розбираємо.
Через добу після запуску власник відкрив кілька російських сторінок і побачив те, чого в одному URL бути не повинно. razrabotka/sajty/razrabotka-saita-uslug: sajty написано в українському стилі, saita — у російському, і це один рядок. Або dizajn/dizajn-sistemy/dizain-sistema-produkta — dizajn двічі, dizain один раз, у сусідніх сегментах.
Причина — у тому, звідки бралася кожна частина шляху. Куровану мапу напрямів і категорій писали руками, в українському стилі. Хвости, тобто назви конкретних сторінок, генерувала таблиця транслітерації, і вона знала російські правила. Дві системи зійшлися в одному рядку, і кожна лишила свій підпис.
Заразом виправили ще одну дрібницю, яка й дала статті назву: російське «й» передавали через i, хоч усталене написання латиницею — y. Тобто sayt, а не sait. Так seo-yuridicheskoi-kompanii стало seo-yuridicheskoy-kompanii, sajty — sayty, integraciya-sms-uvedomlenii — integraciya-sms-uvedomleniy. Разом перегенерували 76 адрес.
Чи варта така дрібниця перегенерації? Змішана транслітерація нічого не ламає: сторінка відкривається, пошуковик її бачить. Але такий рядок не продиктуєш по телефону й не скопіюєш без помилки, а кожен місяць робить виправлення дорожчим, бо адреса накопичує історію в індексі. Ми вирішили, що переносити покази зараз дешевше, ніж через рік.
Шість днів 404
Механізм переїзду на той момент уже існував: через нього з 18 серпня переїжджали українські адреси на мовні. Але покривав він лише один тип зміни.
Він шукав стару сторінку лише за українським slug'ом. Мовна адреса, яка змінила написання, до нього просто не доходила: запит на …-kompanii з i не збігався ні з чим, і сервер віддавав 404. Так було з кожною старою адресою з i, з вечора 19 серпня до дня 25 серпня — близько шести днів.
Виправлення вийшло 25 серпня. Тепер, коли точного збігу немає, адреса зводиться до огрубленої форми — «y» і «j» перетворюються на «i», — і обидва написання сходяться. Редирект ставиться лише тоді, коли збіг рівно один. Якщо варіантів кілька, сайт чесно віддає 404, а не вгадує.
На момент виправлення стара адреса юридичної сторінки мала в консолі за 28 днів 310 показів на середній позиції 22 і жодного переходу. Це була друга за показами сторінка сайту, і Google показував у видачі адресу, якої вже не існувало.
Найдивніше тут інше. Адреса з i пропрацювала як робоча трохи більше доби, з 18 на 19 серпня. Google за цей час встиг її підхопити й потім показувати сотнями разів. Швидко підхоплює, повільно відпускає — на цьому тримається вся подальша таблиця.
Що показала консоль через п'ять тижнів
Зріз 24 вересня, період 26 серпня — 22 вересня, 28 днів. Ми прогнали через curl з User-Agent Googlebot усі 227 російських адрес, що мали покази, і знайшли 23, які досі віддають 308. Разом вони набрали 1 058 показів (8,3 % сайту), але 11 із них — інші переїзди, до цієї історії не причетні.
Наслідок перейменування 19 серпня — 12 адрес. На них 663 покази, 5,2 % усіх показів сайту, і один клік. Для 7 із 12 Google уже показував у видачі й нову адресу; для решти п'яти — поки лише стару.
Динаміка по тижнях для цих 12 адрес, з окремою колонкою для юридичної сторінки:
| Тиждень від | Старі | Нові | Усього по сайту | Частка старих | Юридична: стара / нова |
|---|---|---|---|---|---|
| 03.08 | 0 | 0 | 1 498 | 0,0 % | 0 / 0 |
| 10.08 | 0 | 0 | 1 096 | 0,0 % | 0 / 0 |
| 17.08 | 326 | 1 | 2 831 | 11,5 % | 310 / 0 |
| 24.08 | 418 | 0 | 2 451 | 17,1 % | 390 / 0 |
| 31.08 | 172 | 1 | 2 537 | 6,8 % | 164 / 0 |
| 07.09 | 3 | 33 | 4 011 | 0,1 % | 1 / 28 |
| 14.09 | 89 | 210 | 3 959 | 2,2 % | 87 / 196 |
| 21.09 | 8 | 21 | 351 | 2,3 % | 8 / 21 |
Пік частки старих адрес, 17,1 %, припав на тиждень 24 серпня. Перші два дні того тижня старі адреси ще віддавали 404, решту — вже редиректили, але Google показував їх далі: видача не встигала ні за поломкою, ні за виправленням. Нові ж майже не з'являлись у видачі аж до тижня 7 вересня, приблизно два тижні після того, як запрацював редирект.
Останній рядок неповний: дані консолі доходять із затримкою в два-три дні, тому з повними тижнями його не порівнюємо.
Юридична сторінка: сума каже одне, тижні — інше
Якщо дивитися на 28 днів разом, картина виглядає як поразка. Стара адреса …/seo-yuridicheskoi-kompanii — 631 показ на позиції 22,8 і один клік. Нова, …/seo-yuridicheskoy-kompanii, — 245 показів на позиції 38,4.
Але в тижневому розрізі нова вже обігнала стару: на тижні 14 вересня — 196 показів проти 87. Сума за місяць тягне за собою серпневий хвіст, коли стара адреса збирала покази в порожнечу, і ховає, що перенесення фактично вже відбувається. Тому, дивлячись на свої дані, беріть тижні, а не місяць.
Чого з цих даних не випливає
Ми не знаємо, скільки трафіку коштували шість днів 404. Кліків на цих адресах одиниці, різниця в межах шуму, і будь-яка цифра «втрат» була б вигаданою.
Не випливає й те, що редирект «не працює». З 25 серпня він працює; повільним є перенос у видачі, а на нього ми не впливаємо.
Чи було б перенесення швидшим без тих шести днів, сказати теж нічим: контрольної групи немає.
І масштаб. Один сайт, 76 адрес, з яких у видачі взагалі з'являлась лише частина, а зараз зі старою адресою — 12. Це наш досвід, а не закон.
Як повторити перевірку в себе
- Візьміть у Search Console звіт за сторінками за 28 днів — вивантаженням або через API.
- Прогоніть кожну адресу через
curl -s -o /dev/null -w "%{http_code} %{redirect_url}" <адреса>і виділіть 301, 308 і будь-які 404. Не в 16 потоків: важкі сторінки не встигають відповісти, а обірвана відповідь читається як помилка сайту. Без терміналу — перевірка кодів відповіді. - Порахуйте частку показів на адресах-редиректах і дивіться її по тижнях. Сума за місяць сховає, що нова адреса вже обігнала стару.
- Для кожної старої адреси
curl -sILмає показати один перехід, без ланцюга.
З власної історії ми винесли кілька правил. Міняти адреси — лише коли є причина. Якщо міняти, то редирект готовий до того, як нові адреси з'являться в карті сайту. І перевіряти його треба на всіх змінених адресах, а не на одній: механізм переїзду в нас був, просто покривав лише один тип зміни. На перехідний період закладайте тижні, а не дні.
Про суміжні поломки ми писали окремо: карта сайту, яка суперечить самим сторінкам і куди витрачається обхід сайту. Якщо потрібно, щоб зміну адрес спланували й перевірили за вас, це технічне SEO; окремо про 404 і биті посилання — тут.
