Міграцію не можна зробити так, щоб у Google не змінилося взагалі нічого. Google сам пише, що в середнього сайту йдуть тижні, а у великого і довше, перш ніж замість старих адрес почнуть показуватися нові, і що під час переіндексації коливання позицій нормальне (документація Google Search Central про переїзд сайту зі зміною адрес).
Питання, отже, не в тому, чи зрушиться щось. Питання в тому, наскільки глибоким і довгим буде цей зсув і за чим ви зрозумієте, що це нормальний хід, а не поломка. Ця стаття описує роботу, яка різницю між цими двома випадками і створює.
Карта URL будується з чотирьох джерел, бо кожне окремо бреше
Карта 1:1 означає, що для кожної наявної адреси старого сайту призначено одну цільову адресу на новому. Не категорія, не головна, одна конкретна сторінка.
Перелік старих адрес не можна взяти з одного місця. Кожне джерело бачить свою частину сайту, і всі чотири треба об'єднати:
- Обхід старого сайту. Дасть те, що із сайту перелінковане. Не побачить сторінки, на які вже ніде немає посилання, а Google їх в індексі тримає.
- Search Console, звіт «Сторінки». Дасть те, що Google справді знає, включно з адресами, про які ви забули.
- Аналітика за останні 12 місяців. Дасть те, куди люди реально ходять, включно із сезонними сторінками, яких в інший період не побачите.
- Зворотні посилання. Дадуть адреси, які цінні, навіть якщо на них заходять двоє людей на рік. Їх перенаправляють насамперед.
Об'єднаний перелік зазвичай на третину довший за обхід, і різницю становлять саме ті адреси, втрата яких помітна лише за місяць.
Параметри, посторінкова навігація і фільтри: три рішення, а не три проблеми
Тут карта 1:1 перестає діяти, і це нормально, просто це має бути рішенням.
Посторінкова навігація (?page=2) перенаправляється на першу сторінку нового списку. Друга сторінка категорії після міграції зазвичай містить інший товар, тож редирект на ?page=2 нового сайту - збіг, а не відповідність.
Фільтри і сортування (?barva=cerna&razeni=cena) перенаправляються на категорію без параметрів, якщо новий сайт не має тих самих фільтрів із тими самими значеннями. Чи мають фільтри мати власні індексовані адреси - окреме рішення, яке ухвалюють до міграції, а не під час неї.
Пошукові та відстежувальні параметри (?q=, ?utm_source=) не перенаправляються по одному. Вирішуються правилом, яке відкидає параметри й обробляє решту адреси.
Перенаправляється одразу на ціль, а не через посередника
Googlebot витримає в ланцюжку до 10 переходів, але Google прямо радить ланцюжків уникати і перенаправляти одразу на фінальну адресу.
Це важливо для сайту, який одну міграцію вже пережив: старий редирект із минулого переходу складається з новим, і ланцюжок виникає без чийогось наміру. Тому перед запуском перевіряють не те, що адреса відповідає, а скільки переходів їй для відповіді знадобилося.
Використовується постійне перенаправлення кодом 301 (або 308). Редирект 302 каже «я повернуся», і Google поводиться відповідно: сигнали переносить не так, як вам потрібно.
Перенаправлення лишають жити щонайменше рік. Google каже це прямо, і це дешево: пара сотень рядків у конфігурації проти ризику за десять місяців дізнатися, на скількох чужих сайтах на вас вело посилання.
Карта редиректів - майно, за яким треба стежити
Ось чого ніхто не чекає: карта редиректів псується сама, навіть якщо її ніхто не чіпає.
В одній міграції, карту якої ми розбирали, було 4 721 запис, і 49 із них вели на неробочу ціль. Розбивка за причинами повчальніша за саме число:
| Причина | Кількість | Що сталося |
|---|---|---|
| Ціль - чернетка товару | 25 | товар хтось зняв із продажу |
| Цілі не існує | 11 | сторінку хтось видалив |
| Ціль - неопублікована сторінка | 3 | сторінка чекає на погодження |
| Ланцюжок редиректів | 10 | додався другий редирект |
Жодна з цих причин не виникла під час міграції. Усі виникли після неї, звичайною операційною роботою: хтось вивів товар, хтось перейменував категорію. Карта редиректів тим самим - перелік, який перевіряють регулярно, а не файл, який один раз завантажили і забули.
Під час міграції зникають не адреси, а текст
На URL дивляться всі. Те, що втрачається частіше і що майже ніколи не перевіряють, - вміст сторінок.
Порівнюючи старий сайт із новим, на одному проєкті ми наміряли падіння обсягу тексту на восьми комерційних сторінках на 53 %, з 13 389 до 6 275 слів, а на сторінках послуг на 63-75 %. Головний фаховий термін, на який сайт довго цілився, впав із 89 входжень до 25.
Механізм банальний і тому його пропускають. Новий сайт зібраний із блоків, карток і переваг у сітці. У сітку не вміщається таблиця з параметрами, огляд норм чи абзац про те, чого метод не вміє, - і під час переносу це лишають осторонь. Обсяг сайту загалом при цьому може зрости, тож втрата не видна.
Практичний наслідок: до міграції виписують вміст, який у новий шаблон не вміщається, і вирішують щодо нього свідомо. А не за падінням через три місяці.
Інструмент Change of Address діє лише на зміну домену
Тут час витрачають регулярно. Інструмент Change of Address у Search Console застосовується лише тоді, коли ви переїжджаєте з одного домену чи піддомену на інший, тобто example.cz на example.com. На зміну структури адрес усередині одного домену і на перехід із HTTP на HTTPS він не застосовується взагалі.
Нову карту сайту в Search Console надсилають, стару потім можна прибрати.
Перші 30 днів: що відстежують і в якому порядку
Не все одразу. У кожного тижня своє питання.
День запуску. Перевіряють вибірку адрес, а не їхній перелік: десять найвідвідуваніших сторінок, десять із найбільшою кількістю зворотних посилань і десять випадкових із глибини каталогу. У кожної перевіряють код відповіді і кількість переходів.
Перший тиждень. Питання звучить «чи бачить Google новий сайт взагалі?». Дивляться звіт про індексування сторінок: зростає кількість проіндексованих нових адрес і з'являються старі адреси в категорії «Сторінка з переспрямуванням». Це правильний стан, а не помилка.
Другий і третій тиждень. Питання звучить «чи не зникло щось зовсім?». Порівнюють перелік сторінок із кліками із Search Console до міграції і після. Цікаві не позиції, а адреси, які випали з видачі цілком.
Четвертий тиждень. Лише тут має сенс дивитися на суми кліків і показів. Раніше ні, бо Google ще не завершив переіндексацію і число описує хід, а не результат.
Що нормальний хід, а що поломка
Різниця видно за формою, а не за величиною падіння.
Нормальний хід: покази падають, кількість проіндексованих старих адрес знижується, кількість нових зростає, старі адреси відповідають 301 за один перехід. Сайти в початковий обсяг повертаються поступово; у великого каталогу це довше.
Поломка: у Search Console додаються помилки 404, у звіті з'являється «Сторінка-дублікат без канонічної адреси», або старі адреси відповідають кодом 200 замість редиректа. Останній випадок найгірший і водночас найчастіший: старий сайт лишився працювати і конкурує сам із собою.
Чого не можна обіцяти заздалегідь: наскільки і чи надовго. Хто це обіцяє, обіцяє за Google. Ми замість обіцянки даємо карту, контрольний перелік і числа, якими ви перевірите хід самі.
Шість питань підряднику з міграції
Працюють на будь-кому, не лише на нас.
- Зі скількох джерел ви збираєте перелік старих адрес і з яких?
- Хто вирішує щодо параметрів, посторінкової навігації і фільтрів і коли?
- Як ви перевіряєте кількість переходів у редиректі, а не лише його наявність?
- Як довго редиректи лишаться в роботі?
- Хто і як часто перевіряє карту редиректів після запуску?
- Хто порівняє вміст старих і нових сторінок за абзацами?
Міграцію не оцінюють у день запуску і навіть за тиждень після. Її оцінюють за місяць, і оцінюють порівнянням переліку адрес, а не відчуттям від графіка.
Потрібна карта раніше, ніж ви вирішите переїжджати
Карту URL і оцінку ризику ми вміємо зробити ще до того, як буде ухвалене рішення про платформу. Потрібен доступ у Search Console, вивантаження адрес зі старого сайту і інформація, скільки з каталогу має лишитися.
Що ми будуємо і на що мігруємо, описано на сторінці розробки інтернет-магазинів. Швидкість нового сайту вирішуємо на сторінці аудиту і пришвидшення сайту - Core Web Vitals після міграції змінюються, і це одна з небагатьох речей, які повністю під вашим контролем.
Напишіть на info@lamapixel.com або телефонуйте +420 775 599 009.
