Новий сайт запустили. А Google досі шукає старий

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

Через два тижні виявляється, що полетіли не всі ракети. У Search Console повзе вгору рядок «Не знайдено (404)», менеджери кажуть, що з сайту пишуть менше, а розробник спокійно пояснює: «Це нормально, Google переіндексує».

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

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

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

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

Адреси змінюються частіше, ніж здається, і новий домен тут лише один із випадків. Ось інші:

• нова CMS або конструктор: у кожної платформи свій формат адрес;
• нова структура каталогу: товар переїхав з /rushnyky/bilyi-rushnyk у /tekstyl/rushnyky/rushnyk-bilyi-70x140;
• зміна мовних версій: з’явився або змінився префікс /ua/, /ru/, /en/;
• перехід з HTTP на HTTPS або з www на адресу без www;
• «просто редизайн», під час якого розробник заодно «почистив» адреси, бо старі були некрасиві.

Google описує такі випадки як переїзд сайту зі зміною URL і прямо радить зіставити старі адреси з новими.

У нашому випадку за день до запуску ми зняли повний список адрес старого сайту: 1962 сторінки, по 981 на кожну мовну версію. Наступного дня, вже після релізу, перевірили кожну з них. 1675 адрес віддавали 404. Ще 247 відкривалися, 40 мали перенаправлення.

Це не означає, що магазин того ж дня втратив 85% відвідувачів: частину сторінок майже ніхто не відкривав. Але для Google це 1675 дверей, за якими раптом стіна.

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

Тому першим пунктом, ще до обговорення дати релізу, збери інвентар зі кількох джерел:

• sitemap.xml старого сайту. Швидкий старт, але не повний список.
• Search Console → Ефективність → Сторінки. Вивантаж усі сторінки, які за останні 12-16 місяців отримували покази й кліки. Це список того, що реально працює в пошуку.
• Звіт про цільові сторінки в аналітиці. Сторінки, з яких люди починали візит, з будь-якого джерела.
• Обхід сайту краулером, наприклад Screaming Frog. Він знайде сторінки, на які ведуть внутрішні посилання, навіть якщо їх немає в карті сайту.
• Зовнішні посилання зі звіту «Посилання» в Search Console. Сторінки, на які посилаються інші сайти, мають найвищий пріоритет.
• Адреси з реклами й товарного фіду. Оголошення, які ведуть на неіснуючу сторінку, марнують бюджет щохвилини.

Тут же перевір дрібницю, яка потім коштує нервів: хто має доступ до Search Console і аналітики. Якщо кабінети записані на підрядника, який робить новий сайт, а він після запуску зникне, ти втратиш і історію, і інструмент, яким міряти наслідки. Про те, які доступи має тримати бізнес, я детально писав у статті «Підрядник зник. Що залишилося від твого сайту?».

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

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

Коли ми обійшли живий сайт, з’ясувалося, що російська версія на місці: 697 сторінок, повне дзеркало української. Вона просто перейшла на українські адреси з префіксом /ru/ і не потрапила в sitemap. Разом із нею поза картою сайту лишилися статті блогу. Загалом 770 живих сторінок не було в sitemap. Якби ми повірили карті, половина магазину залишилася б без перенаправлень, а рішення «закрити ринок» ухвалили б за клієнта, хоча ніхто його не ухвалював.

Карта редиректів - звичайна таблиця з двома колонками: стара адреса і нова. Складність у тому, що кожен рядок потребує рішення. Я раджу тримати чотири правила.

Сторінка є на новому сайті: веди прямо на неї. Той самий товар, та сама послуга, та сама стаття. Без проміжних кроків.

Сторінки немає, але є близький розділ: веди на розділ. Товар зняли з продажу, а категорія з аналогами лишилася. Людина, яка шукала білий рушник 70×140, побачить інші білі рушники, а не порожнечу. Google вважає таке об’єднання прийнятним.

Аналога немає взагалі: чесна 404 або 410. Не кожну сторінку треба рятувати. Акція 2021 року чи товар, якого більше не буде і який нічим не замінити, можуть просто зникнути. Для Google 404 і 410 означають одне й те саме: контенту більше немає, адресу з часом приберуть з індексу.

Не перенаправляй усе на головну. Це найпопулярніший «швидкий фікс», і він не працює. Google прямо пише, що масове перенаправлення старих адрес на одну нерелевантну сторінку, наприклад головну, плутає людей і може вважатися soft 404. Тобто формально редирект стоїть, а для пошуку це та сама зникла сторінка, тільки з зайвим кроком.

Хто заповнює таблицю? Коли адрес кілька тисяч, вручну це довго, тому зіставлення частково автоматизують: порівнюють назви сторінок, заголовки, артикули. І тут чекають пастки.

У нашому каталозі автоматичне порівняння назв охоче з’єднувало товари, які відрізнялися одним словом. «Рушник банний 70×140, білий» і такий самий сірий. Термокружка чорна і графітова: схожість назв 0,87, а товар інший. Для скрипта це майже ідеальна пара. Покупець, який прийшов по чорну кружку, побачить магазин, що не знає власного асортименту.

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

Категорійні пропозиції для знятих товарів ми перевірили на випадковій вибірці з 25 пар. Правильних було 24. Єдина помилка показова: чохли для подушок отримали категорію з посудом. Людина бачить цю помилку за п’ять секунд. Скрипт її не бачить взагалі.

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

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

Таблиця готова. Тепер її треба перетворити на налаштування сервера чи модуля CMS. Ось що я перевіряв би перед тим, як погодити реліз.

Постійний серверний редирект. Google рекомендує постійне перенаправлення на рівні сервера: код 301 або 308. Тимчасові 302 і 307 означають «сторінка скоро повернеться», і тоді в пошуку може залишатися стара адреса. Перенаправлення через JavaScript лишай на крайній випадок: якщо скрипт не відпрацює, Google може його не побачити.

Без ланцюжків. Стара адреса має вести одразу на фінальну, а не через дві проміжні. Ланцюжки з’являються, коли сайт переїжджає вдруге, а старі правила ніхто не оновив.

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

Тримай редиректи довго. Google радить щонайменше рік. Я раджу не видаляти їх, поки вони нікому не заважають. Старі посилання на форумах і в чужих статтях не оновляться ніколи.

Внутрішні посилання ведуть на нові адреси. Меню, футер, перелінковка в статтях, кнопки в листах: усе має вказувати на нові URL. Редирект рятує зовнішніх відвідувачів, але сайт, який посилається сам на себе через перенаправлення, виглядає як квартира, де кожні двері ведуть у коридор.

Нова карта сайту повна й чесна. У sitemap мають бути всі живі канонічні сторінки всіма мовами, включно з блогом, і жодної адреси з помилкою чи редиректом. Після запуску надішли її в Search Console.

Новий домен потребує окремого кроку. Якщо змінюється сам домен або піддомен, у Search Console є інструмент зміни адреси. Для переходу на HTTPS чи зміни структури на тому самому домені він не потрібен.

Ще одна моя порада, яку легко вважати перестраховкою: не поєднуй усе в один реліз. Новий домен, нова CMS, нова структура, нові тексти і нова мовна версія того самого дня дають п’ять змінних. Якщо трафік просяде, ти не дізнаєшся, яка з них винна.

Цю історію я люблю найбільше: звіт у ній кілька тижнів робив усіх щасливими.

На початку жовтня звіт показував чудову динаміку органічного трафіку. У GA4 сесії з органічного пошуку зростали: 694 у липні, 1802 у серпні, 3394 у вересні. Новий сайт, нова структура, і SEO нарешті полетіло. Можна відкривати шампанське і замовляти ще один редизайн.

Ми звірили ці цифри з Search Console, бо вона рахує саме кліки з пошуку Google. Картина там була зовсім інша: кліки за ті самі місяці майже не рухалися, 511, 567, 581. Покази взагалі зменшувалися: приблизно 57 тисяч, 51 тисяча, 42 тисячі. Зате в GA4 в ті самі дні обвалився інший канал: Cross-network, через який аналітика показує трафік кампаній Performance Max. 2704 сесії в липні, 554 у вересні.

Органіка «зросла» рівно на стільки, на скільки «впала» реклама. Чудес не буває, бувають редиректи.

Причина знайшлася в налаштуваннях SEO-модуля нового сайту. Товарні сторінки робили перенаправлення 301 на ту саму адресу, але без параметрів після знака питання. Разом з «некрасивими» параметрами сайт вирізав і службові: gclid, за яким Google Ads пов’язує клік із конверсією, мітки utm_*, fbclid. Реклама Performance Max вела саме на товари. Людина клікала на оголошення, сайт мовчки стирав мітку, і GA4 бачив звичайний перехід з google.com. Тобто органіку.

Google Ads прямо попереджає: якщо сайт використовує перенаправлення, параметр GCLID має дійти до фінальної сторінки, інакше конверсії не відстежуються. Тут він не доходив. Наслідок подвійний: звіт малював SEO-ріст, якого не було, а рекламна система гірше бачила, які кліки принесли замовлення, і гірше вчилася.

Саме виправлення виявилося простим: у модулі увімкнули дозволені параметри й додали до них список службових міток. Після цього адреса з ?gclid= відкривається напряму, без перенаправлення. Дані за майже два місяці вже не перерахуєш, тому органіку за цей період ми рахуємо з Search Console, а не з GA4.

Чому я наполягаю на цьому пункті окремо: цю поломку ніхто не відчуває. Сайт відкривається, реклама крутиться, звіт тішить. Без звірки двох джерел вона може жити роками.

Як перевірити в день запуску:

1. Відкрий кілька типових сторінок, на які веде реклама: товар, категорію, посадкову.
2. Додай до адреси ?gclid=test&utm_source=test.
3. Подивись, чи параметри лишилися в адресному рядку після завантаження.

Розробник може перевірити кінцеву адресу командою curl -LsS -o /dev/null -w '%{http_code} %{url_effective}' "https://твій-сайт/сторінка?gclid=test": сторінка має відкритися з кодом 200, а gclid=test залишитися в кінцевій адресі. Проміжний 301 допустимий, якщо він передає параметр далі. Про те, як узагалі зв’язати рекламний клік із реальною угодою, я писав окремо в статті «Відстеження конверсій у B2B Google Ads: від ліда до доходу». Базові події в GA4 після переїзду теж варто перевірити заново, інструкція є в статті про GA4 для малого бізнесу.

Після запуску є спокуса або панікувати від кожного графіка, або закрити вкладку Search Console на квартал. Обидва варіанти погані.

День запуску. Прожени весь список старих адрес і запиши відповідь кожної: 301 і куди саме, 200, 404. Перевір параметри реклами, як у попередньому розділі. Відправ тестову заявку з кожної форми й переконайся, що вона дійшла до людини, а не лише показала «Дякуємо»: як це зробити, розібрано в статті «Форма сказала “Дякуємо”. А заявка куди поділася?». Надішли нову карту сайту.

Перший тиждень. Дивись звіт «Сторінки» в Search Console: скільки адрес з’явилося в групі «Не знайдено (404)» і які саме. Перевір ключові сторінки через інструмент перевірки URL. Порівнюй кліки й покази з тим самим періодом до запуску, а не з учорашнім днем. І рахуй реальні звернення з пошуку, а не лише сесії.

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

У нашому магазині приблизно через вісім тижнів після запуску Search Console показувала 538 адрес у звіті про 404. Звучить як «усе зламалося», але це просто список справ, який треба розсортувати. Ми пройшли кожен рядок:

• 495 адрес отримали 301. З них 240 вели на той самий товар чи його варіант, решта на найближчу категорію;
• 21 адреса не мала жодного живого аналога, тому лишилася з чесною 404;
• 12 адрес уже мали перенаправлення: Google просто ще не повернувся їх перевірити;
• 8 адрес були сторінками пагінації, яких немає в новій карті сайту. Тут потрібен не редирект, а пошук, звідки Google їх узагалі бере;
• 2 адреси потребували правила на рівні сервера, бо модуль із ними не впорався б.

Тепер про покази, які з липня по вересень впали приблизно на чверть. Я не можу чесно сказати, яка частина падіння пояснюється переїздом, а яка сезоном чи змінами у видачі. Саме тому до запуску варто зафіксувати базову лінію: кліки, покази, позиції головних сторінок і кількість звернень за кілька місяців. Без неї будь-яка розмова після релізу перетворюється на суперечку відчуттів.

Якщо хочеш ширше перевірити здоров’я сайту вже після переїзду, у статті Оксани Чуприної «Технічний SEO-аудит перед контентом» є перелік перевірок, які варто пройти до того, як вкладатися в нові тексти.

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

Останнє речення можна прибрати, якщо стосунки з розробником ніжні. Але сенс у ньому правильний.

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

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