Міграція з WordPress на кастом без втрати SEO

Як перенести сайт із WordPress на кастомну розробку без втрати SEO-трафіку

Відмова від WordPress — це не лише про дизайн. Якщо пошуковий трафік має значення, міграцію треба починати зі сторінок, які вже приносять кліки, ліди й посилання. Фраза “як перенести сайт із WordPress на кастомну розробку без втрати SEO-трафіку” звучить довго, але сама робота цілком практична: спершу захистити те, що вже ранжується, а вже потім перебудовувати сайт навколо цих сторінок. Саме такий порядок рятує від проблем у майбутньому.

Одна з найпоширеніших помилок — вважати, що всі URL однаково важливі. Архів блогу з 200 відвідуваннями на місяць не заслуговує такої ж уваги, як сторінка послуги, яка приносить 2 000 відвідувань і десяток беклінків. Визначте 10, 20 або 50 URL, які мають найбільше значення, і зафіксуйте їх до початку будь-яких змін у коді. Малий список — великий ефект.

1. Позначте сторінки, які реально приносять пошуковий трафік

Почніть із трьох джерел: аналітики, Search Console та даних про беклінки. В аналітиці знайдіть цільові сторінки, що отримували органічний трафік протягом останніх 12 місяців. У Search Console подивіться, які запити приносять покази та кліки на ці URL. У даних про посилання позначте сторінки з найсильнішими зовнішніми лінками, бо сторінка з 5 якісними посиланнями може обігнати 50 слабких.

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

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

2. Зафіксуйте поточну SEO-базу до будь-яких змін у коді

Перш ніж розробник торкнеться шаблонів, експортуйте поточний SEO-стан. Збережіть знімки позицій, кількість проіндексованих сторінок, помилки сканування, canonical, метадані, внутрішні посилання та URL із XML sitemap. За можливості проскануйте сайт на WordPress інструментом, який записує статус-коди й заголовки сторінок. Вам потрібна “фотографія” до змін, а не туманний спогад.

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

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

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

3. Сплануйте URL-еквівалентність для кожної важливої сторінки

Тепер зіставте кожен важливий URL на WordPress із новим кастомним URL. По можливості зберігайте зв’язок один до одного. Якщо стара сторінка — це /services/seo-audit/, нова не повинна стати /what-we-do/consulting/audit/, якщо немає дуже вагомої бізнес-причини. Чітке зіставлення зменшує складність редиректів і полегшує перевірку міграції.

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

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

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

4. Разом сплануйте редиректи, canonical та сигнали індексації

Одних редиректів недостатньо. Якщо сторінка перенаправляє на новий URL, але canonical вказує кудись іще, сигнали стають заплутаними. Якщо сторінка заблокована в robots.txt, але є в sitemap, це теж створює хаос. Пошуковики люблять один чіткий сценарій. Дайте їм саме його.

Задайте 301-редиректи для кожного старого URL, якому потрібен новий дім. Уникайте ланцюжків редиректів. Один перехід — добре. Два — ще терпимо в екстреному випадку. Три — це вже точка, де починають втрачатися трафік і ефективність сканування. Для глибшого технічного чекліста дивіться як налаштувати 301-редиректи.

Canonical мають вести на бажану версію кожної сторінки на новому сайті. Якщо відфільтрована сторінка має лишатися індексованою, зафіксуйте це окремо. Якщо сторінка на основі параметрів не має індексуватися, зробіть так, щоб директива robots і canonical відповідали цій меті. Змішані сигнали витрачають crawl budget і розмивають релевантність сторінки.

XML sitemap повинні містити лише ті URL, які мають індексуватися і віддають відповідь 200. Видаліть старі URL WordPress із sitemap у день запуску, а не через тиждень. Sitemap із “мертвими” URL — це як карта з дорогами, що впираються в стіну. Боти це помічають.

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

5. Збережіть on-page SEO під час відтворення шаблонів

Відтворення шаблонів — це місце, де багато міграцій втрачають динаміку. Дизайнер змінює ієрархію заголовків, бо “так краще виглядає”, або розробник обрізає meta description, бо вони здаються невидимими. Але пошуковики все ще читають ці елементи. І користувачі теж — опосередковано, через сніпети та sitelinks.

Перебудуйте title tags так, щоб вони залишалися конкретними для кожної сторінки. Збережіть meta description там, де вони й далі відповідають змісту. Підтримуйте чітку структуру H2 або H3 на сторінці замість хаотичних стрибків між рівнями заголовків. Якщо старий WordPress-шаблон використовував описовий H1 із підтримуючими H2, відтворіть цю логіку в кастомній збірці.

Структуровані дані заслуговують на таку саму увагу. Якщо старий сайт розмічав статті, товари, хлібні крихти або FAQ, перевірте, які типи schema залишаються актуальними в новій версії. Відсутність schema не завжди обвалює позиції, але видалення валідного типу сторінки може знизити шанси на rich results. Це реальна втрата, навіть якщо її складно виміряти.

Alt-текст для зображень теж важливий. Якщо сторінка на WordPress містила зображення, які приносили покази в пошуку картинок, залиште alt-тексти описовими й конкретними. Не замінюйте “Зустріч команди в Берліні” на “image1”. Одна така зміна може швидко знизити видимість у пошуку зображень.

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

6. Опрацюйте крайні випадки контенту й медіа, які приховує WordPress

WordPress приховує чимало зайвого. Сторінки вкладень — класичний приклад. Вони можуть створювати “тонкі” URL, які пошуковики сканують, індексують, а потім ігнорують. Сторінки автора й теги можуть поводитися так само. Якщо вони не корисні, приберіть їх із індексації або консолідуйте зі сильнішими сторінками.

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

Ще одна пастка — “осиротілий” контент. У WordPress сторінка може залишатися в базі даних довго після того, як вона зникла з навігації. Під час міграції про таку сторінку легко забути, бо її не видно в меню. Але пошуковики можуть її все ще бачити. Зробіть експорт контенту, який включає кожен URL, що може публікуватися, а не лише сторінки, які ви пам’ятаєте за назвою.

Для великих редакційних сайтів етап очищення також може виявити дублікати або майже дублікати публікацій. Деякі з них варто об’єднати. Іншим може знадобитися тег noindex. Приймайте рішення на основі трафіку, посилань і релевантності, а не лише редакційних уподобань. Пошуковики не сентиментальні.

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

7. Перевірте запуск за допомогою QA, орієнтованого на пошуковики

QA має відбуватися двічі: на staging і після запуску. Проскануйте staging-сайт за тими самими правилами, які плануєте відкрити публічно. Перевірте статус-коди, canonical, внутрішні посилання, метадані та вивід sitemap. Переконайтеся, що старі URL WordPress віддають потрібний 301-відгук, а сторінка призначення повертає 200.

Шукайте петлі редиректів, змішані протоколи та випадкові noindex. Сторінка, яка має ранжуватися, але позначена noindex, не відновиться сама по собі. Сторінка, що редиректить з HTTP на HTTPS, а потім на інший шлях, може й працювати для користувачів, але це додає ризику. Один чистий редирект — саме те, до чого треба прагнути.

Порівняйте staging із базою, яку ви зафіксували раніше. Чи сильно змінилася кількість URL, доступних для індексації? Чи не втратив головний екран свій canonical? Чи внутрішні посилання все ще ведуть на старі слаги? Такі перевірки виснажливі. Але вони дешевші за падіння трафіку.

Корисно перевіряти QA і через crawler, і вручну. Краулер знаходить відсутні теги. Людина помічає дивні шаблони сторінок, дивні заголовки та зламаний порядок контенту. Розробник може вирішити, що все гаразд, бо сторінка завантажується. Пошуковиків цікавить набагато більше, ніж просто завантаження.

8. Відстежуйте SEO-сигнали після запуску й швидко усувайте втрати

Після запуску щодня дивіться Search Console протягом перших 2–4 тижнів. Відстежуйте охоплення індексації, помилки сканування, зміни позицій і трафік на цільові сторінки. Якщо сторінка, яка раніше ранжувалася, зникає з результатів пошуку, спершу перевірте ціль редиректу, title tag, canonical і внутрішні посилання.

Деякі втрати прості. Сторінку могли перенаправити не туди. Інші — ні. Розділ міг втратити цінність, бо занадто багато старих URL ведуть на загальну головну замість релевантної заміни. Пошуковики люблять конкретику, а не обхідні шляхи.

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

Також слідкуйте за поведінкою сканування. Якщо Googlebot витрачає час на низькоцінні URL, звузьте sitemap і перегляньте правила індексації. Якщо вам потрібен ширший погляд на витрати на вимірювання після запуску, скільки коштує аналітика сайту допоможе спланувати бюджет моніторингу. Для команд, які підтримують новий сайт у здоровому стані з часом, скільки коштує обслуговування сайту — корисне додаткове читання.

Одна остання звичка справді окупається: ведіть журнал змін для кожного редиректу, налаштування canonical і оновлення шаблону після запуску. Якщо позиції просіли на 9-й день, вам потрібно знати, що змінилося на 6-й. Такий журнал перетворює паніку на діагностику, а діагностику — на надійне виправлення. Якщо коротко, то саме так працює міграція сайту з WordPress на кастомну розробку: системно, прозоро й без зайвих сюрпризів. А для команд, які ще на етапі планування, варто окремо подумати про те, як зберегти SEO-трафік при переносі сайту.