Як міграція сайту може зруйнувати SEO навіть без зміни URL

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

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

Наприклад, такі зміни можуть виникнути під час переходу з WordPress на headless-архітектуру з використанням Contentful і Next.js. У такому разі розподіл відповідальності за SEO змінюється: замість плагінів, тем і серверних налаштувань ключову роль починають відігравати поля CMS, компоненти фронтенду, логіка маршрутизації та параметри рендерингу.

Такі зміни можуть призвести до проблем, які складно виявити під час поверхневої перевірки. Наприклад, канонічні посилання можуть зникнути, навігаційні посилання — стати недоступними для сканування, контент може переміститися з початкового HTML-коду в JavaScript-рендеринг, а неіснуючі сторінки замість відповіді 404 можуть повертати код 200.

Щоб виявити такі проблеми, необхідно задокументувати, які SEO-функції забезпечувала попередня платформа, перевірити, як вони реалізовані в новій системі, та зосередити тестування міграції на тих елементах, які зазнали змін.

Визначте, які SEO-функції забезпечувала попередня CMS

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

З’ясуйте, де тепер реалізуються SEO-функції

У WordPress SEO-плагін може автоматично генерувати канонічні посилання, директиви meta robots, XML-карти сайту та структуровані дані. Тема сайту може відповідати за відображення хлібних крихт, пагінацію та навігаційні посилання, тоді як налаштування перенаправлень і серверних відповідей можуть бути реалізовані на рівні застосунку або серверної конфігурації.

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

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

Також може змінитися внутрішня перелінковка. У WordPress тема сайту може формувати пункти меню та блоки рекомендованого контенту за допомогою стандартних HTML-посилань. Під час розробки нового сайту ці компоненти можуть бути реалізовані інакше.

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

Окремої уваги потребують стани сторінок. Наприклад, на старій платформі видалена сторінка могла коректно повертати HTTP-статус 404. У новому застосунку може використовуватися власна логіка резервного відображення: система намагається отримати запитаний маршрут, не знаходить відповідного запису в Contentful і показує повідомлення про відсутність сторінки.

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

Сформуйте базові показники до початку міграції

Перед перенесенням сайту необхідно зафіксувати початковий стан його технічних характеристик для основних типів сторінок і сценаріїв роботи.

Для кожної репрезентативної URL-адреси варто зібрати такі дані:

• HTTP-статус і поведінку перенаправлень.
• Основний контент і важливі SEO-елементи, які присутні в початковому HTML-коді.
• Елементи, що з’являються після рендерингу сторінки.
• Очікувані значення канонічних посилань і директив robots.
• Відображення структурованих даних.
• Важливі внутрішні посилання.
• Поведінку сторінок, які недоступні, видалені або не містять контенту.

Вибірка сторінок має відображати реальну структуру сайту та враховувати різні сценарії взаємодії з ним.

Наприклад, для інтернет-магазину доцільно перевірити:

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

Для інформаційного або корпоративного сайту з блогом вибірка може включати:

• окрему статтю;
• сторінку категорії блогу;
• сторінку автора;
• архівні матеріали.

Зафіксовані дані стануть базовою точкою для порівняння. Вони допоможуть визначити, які характеристики нова реалізація має зберегти, та виявити відхилення після міграції.

Перевірте SEO-функції, реалізація яких змінилася

Після визначення того, які функції та елементи були перенесені на інші рівні системи, можна сформувати план перевірки нової версії сайту.

Перевірте канонічні посилання та структуровані дані

Якщо раніше канонічні посилання генерувалися SEO-плагіном WordPress, а після міграції за це відповідає фронтенд Next.js, необхідно порівняти очікувані та фактичні результати для всіх шаблонів сторінок, які використовують спільну логіку.

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

Якщо структуровані дані раніше формувалися за допомогою плагіна, а тепер генеруються компонентами фронтенду, необхідно перевірити відповідні шаблони та стани сторінок.

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

Під час перевірки Schema.org також важливо враховувати, що втрата коректної мікророзмітки може вплинути на можливість відображення розширених результатів пошуку (rich results). Водночас сама по собі така втрата не обов’язково призводить до зниження позицій сайту в пошуковій видачі.

Порівняйте рендеринг сторінок і внутрішні посилання

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

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

У такому разі потрібно порівняти початковий HTML-код із повністю відрендереною сторінкою та визначити, які саме елементи контенту, посилання й SEO-сигнали змінили спосіб передавання.

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

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

Тому перевірка лише наявності основного контенту не дасть повного уявлення про стан сайту після міграції.

Для навігаційних елементів, хлібних крихт, карток товарів і блоків рекомендованого контенту необхідно перевіряти фактично згенеровані посилання.

Компоненти сучасних фреймворків можуть створювати повністю доступні для сканування посилання, якщо вони правильно реалізовані. Тому не варто робити висновки лише на основі використовуваної технології — необхідно перевіряти кінцевий HTML-код.

Протестуйте маршрутизацію для різних станів сторінок

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

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

Під час тестування варто перевірити:

• видалені сторінки;
• товари, які більше недоступні;
• порожні категорії;
• сторінки пагінації за межами доступного діапазону;
• вибірку некоректних URL-адрес.

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

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

Аналізуйте закономірності в шаблонах і компонентах

Під час тестування важливо не лише фіксувати окремі відмінності, а й шукати закономірності між ними.

Визначайте проблеми у спільних реалізаціях

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

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

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

Наприклад:

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

Для системного аналізу проблеми доцільно класифікувати за такими параметрами:

• шаблон сторінки;
• компонент;
• стан сторінки;
• мовна версія або локаль;
• спосіб рендерингу.

Такий підхід допомагає визначити спільну частину реалізації, яка спричиняє проблему.

Групуйте проблеми для діагностики та пріоритизації виправлень

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

Якщо всі проблемні URL-адреси використовують один шаблон сторінки товару, необхідно перевірити спільну реалізацію мікророзмітки.

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

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

Групування проблем дає змогу точніше сформулювати завдання для розробників і визначити пріоритетність виправлень.

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

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

Контролюйте зміни після запуску нового сайту

Після запуску необхідно зосередити моніторинг на тих елементах реалізації, які були змінені та перевірялися під час підготовки до міграції.

Перевіряйте технічну роботу сайту в production-середовищі

Якщо після міграції змінився спосіб рендерингу сторінок товарів, цю групу URL-адрес потрібно контролювати окремо.

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

Якщо змінилася внутрішня перелінковка, потрібно повторно просканувати сайт у робочому середовищі та порівняти пріоритетні групи URL-адрес із базовими показниками, зафіксованими до міграції.

Особливу увагу варто приділити таким показникам:

• глибина сканування сторінок;
• кількість внутрішніх посилань;
• наявність сторінок-сиріт (orphan pages), на які не ведуть внутрішні посилання.

Зміни в маршрутизації необхідно перевіряти за допомогою сканування production-сайту, серверних логів (якщо вони доступні) та Google Search Console.

Потрібно виявляти неочікувані перенаправлення, некоректну поведінку сторінок із помилкою 404, а також URL-адреси, які повертають успішну відповідь сервера, хоча фактично відображають повідомлення про відсутність контенту.

Важливо перевіряти сайт у production-середовищі навіть тоді, коли всі тести на staging-середовищі пройшли успішно.

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

Аналізуйте ефективність за групами URL-адрес

Після запуску сайту важливо сегментувати не лише технічні помилки, а й показники його ефективності.

Наприклад, якщо після міграції органічний трафік сайту знизився на 3%, сам по собі цей показник не дає достатньо інформації для діагностики.

Можлива ситуація, коли трафік на сторінки товарів суттєво знизився, тоді як інформаційний контент продемонстрував зростання. Або основна частина падіння припадає лише на одну мовну версію сайту.

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

Google Search Console може бути корисною для такого аналізу, якщо структура URL-адрес дає змогу чітко розділити сторінки на відповідні групи.

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

Час виникнення змін також може бути корисним діагностичним сигналом, хоча сам по собі не доводить причинно-наслідкового зв’язку.

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

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

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

Тривалість моніторингу залежить від розміру сайту та частоти сканування його сторінок пошуковими системами.

Незмінні URL-адреси не усувають ризики міграції сайту

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

Попереднє визначення функцій, які забезпечувала стара платформа, дає змогу зрозуміти, що саме потрібно перевіряти під час перенесення сайту та контролювати після його запуску.

Міграція може зберегти всі важливі URL-адреси, але водночас змінити спосіб сканування, рендерингу та інтерпретації сторінок пошуковими системами.

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

Читайте статтю англійською мовою.

How Website Migration Can Damage SEO Even Without Changing URLs