Що входить у міграцію сайту
Ми формуємо співпрацю під конкретний бриф. У пропозиції зазначено, які з цих результатів включено, хто надає вхідні матеріали та як приймається кожен результат.
- Інвентаризація URL-адрес і контенту
- Карта редиректів 1:1, що охоплює кожну стару URL-адресу
- Контент, метадані та медіафайли, перенесені в нову CMS
- Форми, аналітика, згода на cookie та інтеграції, відновлені й протестовані
- Сканування тестового середовища та чек-лист дня запуску
- Огляд пошукових показників через 30 і 60 днів
- Передача акаунтів, DNS і списку редиректів
Коли мігрувати, а коли краще зробити редизайн
Обирайте міграцію, коли контент і структура сайту ще працюють, але платформу, хостинг чи домен потрібно змінити: через зростання витрат, непідтримувані плагіни, повільний конструктор або новий бренд на новому домені. Якщо сторінки більше не пояснюють вашу пропозицію, обирайте редизайн сайту: він передбачає ті самі перевірки в межах нового дизайну. Якщо потрібні лише пошукові виправлення на поточній платформі, почніть із SEO.
Як проходить міграція: інвентаризація, карта, репетиція, перемикання, спостереження
Перш ніж щось переносити, ми фіксуємо все, що робить поточний сайт, а потім на основі цієї інвентаризації складаємо карту редиректів і модель контенту. Новий сайт будується й наповнюється на тестовій адресі, яку пошукові системи не індексують, тож старий сайт працює аж до перемикання.
Перед запуском ми скануємо тестовий сайт за повним списком старих URL-адрес і виправляємо кожну невідповідність. Запуск проходить у заплановане вікно: перемикаємо DNS або хостинг, вмикаємо редиректи, надсилаємо мапи сайту, тестуємо форми реальними відправленнями, а за зміни домену подаємо Change of Address у Search Console. Через 30 і 60 днів порівнюємо індексацію та пошукові показники з базовими значеннями до запуску й виправляємо те, що покажуть дані.
Що фіксується в інвентаризації до початку перенесення?
Усе, що приводить відвідувачів або виконує роботу, а не лише сторінки з меню. Пошуковий трафік часто потрапляє на старі дописи блогу, PDF-файли, відфільтровані списки або сторінки, які роками ніхто не редагував. Якщо URL-адреси немає в інвентаризації, її немає й у карті редиректів, а її відвідувачі та посилання потрапляють на сторінку помилки.
Для кожного рядка ухвалюється рішення: залишити, перенаправити назавжди, об'єднати з еквівалентною сторінкою або прибрати. Також фіксується, від чого залежить сторінка, як-от місце призначення форми, віджет бронювання, скрипт відстеження чи медіафайл, щоб залежність перенеслася разом із нею.
- Кожна URL-адреса, що відповідає, зокрема PDF, зображення та URL із параметрами
- Цільові сторінки з Search Console й аналітики щонайменше за повний рік, щоб врахувати сезонні сторінки
- Зворотні посилання: на які сторінки посилаються інші сайти
- Форми, їхні поля та місце, куди потрапляє кожне відправлення
- Скрипти та інтеграції: CRM, бронювання, чат, платежі, аналітика, згода на cookie
- Медіа та файли для завантаження з їхніми поточними URL-адресами
- Ролі в CMS: хто що редагує і в яких полях
Як редиректи захищають позиції та посилання?
Документація Google щодо переносу сайту радить зіставити кожну стару URL-адресу з новою та налаштувати постійні серверні редиректи. Статус 301 або 308 повідомляє пошуковим системам, що сторінку перенесено назавжди. Кожна стара URL-адреса має вести прямо на найближчий відповідник; Google радить короткі ланцюжки, в ідеалі не більше трьох переходів, і оновлені внутрішні посилання, щоб сайт не залежав від редиректів.
Якщо в сторінки немає справжнього відповідника, вона має повертати 404 або 410. Google радить не перенаправляти багато старих URL-адрес на одну нерелевантну сторінку, наприклад нову головну, і вилучає з індексу адреси, що повертають ці коди. Показуйте звичайну сторінку «не знайдено» з відповідним статусом, щоб відвідувачі зі старих посилань усе одно мали навігацію.
Google також радить зберігати редиректи якомога довше, зазвичай щонайменше рік, і подавати Change of Address у Search Console, коли змінюється домен чи піддомен. Він попереджає, що слід очікувати тимчасових коливань позицій; для малого чи середнього сайту більшості сторінок може знадобитися кілька тижнів. Наша робота обмежує втрати цим періодом стабілізації, без уникних втрат через відсутні редиректи чи непрацюючі сторінки.
Що ламається, коли ви йдете з WordPress, Webflow, Wix, Framer, Squarespace чи Shopify?
Кожна платформа зберігає контент по-своєму, тому експорт і налаштування редиректів відрізняються. Хмарні конструктори, як-от Wix, Webflow, Framer і Squarespace, запускають ваш сайт на власних серверах, тож перенесення — це перебудова на основі того контенту, який кожен із них дозволяє експортувати.
У нашому типовому стеку, Astro на Cloudflare з headless CMS, сторінки віддаються як HTML, редиректи є серверними 301 або 308, а редактори отримують поля для заголовків, описів і alt-текстів. Коли магазину потрібні checkout і застосунки Shopify або команда спирається на знайомі плагіни WordPress, ми переходимо на WordPress чи Shopify з тими самими перевірками.
| Звідки переходимо | Що зазвичай ламається | Що ми плануємо |
|---|---|---|
| WordPress | Шорткоди та розмітка конструкторів сторінок; SEO-заголовки, що зберігаються плагінами поза текстом запису; URL-адреси зображень у /wp-content/uploads/; URL-адреси категорій, тегів, авторів і стрічок; плагіни форм. | Експорт WordPress записує дописи, сторінки, користувацькі поля, категорії, теги й користувачів в XML-файл. Ми зіставляємо метадані плагінів із полями CMS, переносимо медіа на новий хостинг і налаштовуємо редиректи для архівів, що досі отримують трафік. |
| Webflow | Webflow розміщує сайт у себе. Колекції CMS експортуються як CSV, але поля зображень і файлів експортуються як посилання на проєкт Webflow, які, за словами Webflow, перестають працювати, якщо проєкт видалити. | Завантажте всі ресурси до скасування тарифного плану, перепишіть ці посилання та відновіть взаємодії, форми й зв'язки між колекціями. |
| Wix | Wix заявляє, що його архітектура не підтримує зовнішній хостинг, тому сайт не можна перенести на інший хостинг у його поточному вигляді. | Перебудувати сайт на основі робочої версії та контенту, який можна експортувати, зібрати медіафайли, з'ясувати, де зареєстровано домен, і налаштувати редирект для кожної сторінки. |
| Framer | Framer не дає змоги експортувати HTML для власного хостингу; макети й анімації залежать від його платформи. | Відтворити шаблони й анімації, перенести контент CMS у нову модель, зберегти slug-и та метадані. |
| Squarespace | Експорт записує частину контенту у файл XML у форматі WordPress і не включає сторінки магазину, блоки товарів та відеоблоки; експортується лише одна сторінка блогу. | Окремо спланувати перенесення даних магазину, перенести зображення на новий хостинг і зіставити URL кожної колекції. |
| Shopify (до або з) | Фіксовані шляхи, як-от /products/ і /collections/; редиректи працюють лише для URL, за якими більше не завантажується сторінка; облікові записи клієнтів і замовлення потребують окремого плану. | Перехід на Shopify: повний список редиректів для товарів і колекцій, який Shopify приймає масово з файлу CSV. Перехід з Shopify: ці фіксовані шляхи зіставляються з новою структурою. |
Що переноситься, окрім URL, і коли це перевіряється?
URL може правильно перенаправляти, але втратити те, що давало йому позиції чи конверсії. Ці елементи легко загубити, коли контент переноситься файлом експорту або вручну, тому кожен із них перевіряється на нових шаблонах до запуску.
Запуск не закриває обсяг робіт: пропущені URL з'являються в даних через кілька тижнів, тому перевірки з таблиці входять у проєкт.
- Заголовки (title), meta description і підзаголовки, зокрема збережені в плагінах
- Canonical-теги, що вказують на кожен новий URL, і hreflang, оновлений для кожної мови
- Структуровані дані, як-от Organization, Article, Product або LocalBusiness
- URL зображень, alt-текст і файли для завантаження
- Форми та місце призначення кожного надісланого повідомлення
- Події аналітики, конверсії та банер згоди, що ними керує
- Ролі в CMS, щоб редактори могли публікувати наступного дня після запуску
| Коли | Що ми перевіряємо | Тривожний сигнал |
|---|---|---|
| Перед перемиканням | Список старих URL перевіряється краулером на тестовому сервері: кожен повертає 200, один редирект на сторінку з 200 або свідомий 404 чи 410 | Ланцюжки, цикли, масові редиректи на головну сторінку |
| День запуску | Редиректи активні, нову карту сайту подано, noindex із тестового сервера прибрано, форми й аналітику протестовано, для зміни домену подано Change of Address | Форма, повідомлення з якої нікому не надходять; залишений noindex на весь сайт |
| Перший тиждень | Індексація сторінок у Search Console, журнали серверних 404, ручна перевірка найвідвідуваніших сторінок | Старі URL, яких немає в інвентаризації |
| 30-й день | Проіндексовані сторінки, кліки та покази за сторінками порівняно з базовим рівнем | Сторінки, що втрачають покази значно більше, ніж загальні коливання |
| 60-й день | Прогалини виправлено, список редиректів задокументовано, визначено дату перегляду до видалення будь-якого редиректу | Редиректи, втрачені під час зміни хостингу, плагіна чи DNS |
Запитання перед вибором
Чи втрачу я позиції в Google, якщо перенесу сайт?
Певні коливання — це нормально: у документації Google щодо перенесення сайту сказано очікувати тимчасових коливань позицій під час переїзду. Наша робота запобігає втратам, яких можна уникнути, як-от відсутні редиректи, сторінки, спрямовані на головну, втрачені метадані чи залишений noindex із тестового сервера. Ніхто не може гарантувати позиції, але ми покажемо вам базовий рівень, карту редиректів і порівняння після запуску.
Скільки триває перенесення сайту?
Це залежить від кількості URL, того, як контент можна вивести зі старої платформи, інтеграцій і того, як швидко надходять погодження. За словами Google, після перемикання невеликому чи середньому сайту потрібно кілька тижнів, щоб більшість сторінок перемістилися, тому в плані передбачено перевірки на 30-й і 60-й день.
Чи можете ви перенести мій сайт без редизайну?
Так. Міграція «один до одного» зберігає сторінки, контент і URL настільки близькими до оригіналу, наскільки дозволяє нова платформа. Це часто безпечніший перший крок, бо коли платформа й дизайн змінюються водночас, важко зрозуміти, яка зміна вплинула на ваш трафік. Якщо ви також хочете новий дизайн, редизайн сайту охоплює обидва завдання в одному плані.
Що вам потрібно від мене, щоб почати?
Адміністративний доступ до поточної CMS чи конструктора, реєстратора домену та DNS, хостингу, Search Console і аналітики, а також до інструментів форм, CRM, пошти й оплати, підключених до сайту. Якщо ви користуєтеся SEO-інструментом, стане в пригоді експорт зворотних посилань. Нам також потрібна людина, яка може погоджувати рішення щодо редиректів для сторінок із бізнесовою чи юридичною вагою, як-от політики або сторінки товарів.
Скільки коштує перенесення сайту?
Ціна залежить від кількості URL і шаблонів, від того, як контент виходить зі старої платформи (файл експорту, API чи ручне відтворення), інтеграцій, мов, даних магазину та того, чи змінюється дизайн. Сайт на 40 сторінок із чистим експортом — це зовсім інша робота, ніж двомовний магазин із тисячами URL товарів. У пропозиції обсяг міграції розписано по пунктах.
Що буде з моїм старим хостингом і доменом?
Залиште домен: він тримає ваші посилання, а після зміни домену старий має продовжувати віддавати редиректи щонайменше рік, який зазвичай рекомендує Google. Скасовуйте старий хостинг чи тариф конструктора лише тоді, коли новий сайт відповідає на кожен URL, у вас є повний експорт і резервна копія, а жоден редирект від нього не залежить. У документі передачі вказано дату скасування кожного сервісу, щоб ніщо не продовжилося й не закінчилося несподівано.
Кому належить новий сайт і що не входить у послугу?
Вам. Репозиторій коду, хостинг, CMS, домен і аналітика залишаються на вашу компанію, а разом із передачею проєкту ви отримуєте мапу редиректів, тож будь-який розробник зможе підтримувати сайт. Якщо це окремо не погоджено, міграція не включає створення нового контенту, нового дизайну чи постійної SEO-роботи після 60-денної перевірки.
З блогу
- SEO-чеклист для міграції сайту: змінюйте платформу чи домен без втрати позицій
Позиції рідко падають через нову платформу; вони падають, бо URL, що приваблювали трафік, перестали відповідати. Чеклист від інвентаризації URL до 90-го дня.
Джерела та додаткові матеріали
Джерела цієї сторінки з додатковими подробицями від першоджерел.
- Google Search Central: Site moves with URL changesdevelopers.google.com
- Google Search Central: Redirects and Google Searchdevelopers.google.com
- Google Search Console Help: Change of Address toolsupport.google.com
- Google Crawling Infrastructure: HTTP status codesdevelopers.google.com
- WordPress documentation: Tools Export screenwordpress.org
- Webflow: Export CMS content as a CSVwebflow.com
- Wix Help Center: Exporting or embedding your Wix site elsewheresupport.wix.com
- Framer Help: Can I export my website to HTML and self-host it?framer.com
- Squarespace Help Center: Exporting your sitesupport.squarespace.com
- Shopify Help Center: Creating and managing URL redirectshelp.shopify.com