--- title: "Чекліст SEO для міграції сайту: збережіть позиції в Google — Dardo" description: "Змінюйте платформу чи домен без втрати позицій у Google: інвентаризація URL, мапа редиректів 1:1, перевірки в день запуску та що відстежувати протягом 90 днів." url: "https://dardo.studio/uk/blog/website-migration-seo-checklist/" language: "uk" translations: {"en":"https://dardo.studio/en/blog/website-migration-seo-checklist/","es":"https://dardo.studio/es/blog/migrar-pagina-web-sin-perder-posicionamiento/","fr":"https://dardo.studio/fr/blog/checklist-seo-migration-site-web/","de":"https://dardo.studio/de/blog/website-relaunch-seo-checkliste/","it":"https://dardo.studio/it/blog/checklist-seo-migrazione-sito-web/","pt":"https://dardo.studio/pt/blog/checklist-seo-migracao-de-site/","nl":"https://dardo.studio/nl/blog/website-migratie-seo-checklist/","sv":"https://dardo.studio/sv/blogg/checklista-webbplatsmigrering-seo/","pl":"https://dardo.studio/pl/blog/migracja-strony-seo-checklista/","ru":"https://dardo.studio/ru/blog/website-migration-seo-checklist/","ar":"https://dardo.studio/ar/blog/website-migration-seo-checklist/","hi":"https://dardo.studio/hi/blog/website-migration-seo-checklist/","th":"https://dardo.studio/th/blog/website-migration-seo-checklist/","ja":"https://dardo.studio/ja/blog/website-migration-seo-checklist/","ko":"https://dardo.studio/ko/blog/website-migration-seo-checklist/","zh-Hans":"https://dardo.studio/zh-Hans/blog/website-migration-seo-checklist/","zh-Hant":"https://dardo.studio/zh-Hant/blog/website-migration-seo-checklist/"} updated: "2026-10-10T09:03:34.117Z" --- [Блог](https://dardo.studio/uk/blog/) # SEO-чеклист для міграції сайту: змінюйте платформу чи домен без втрати позицій Позиції рідко падають через нову платформу; вони падають, бо URL, що приваблювали трафік, перестали відповідати. Чеклист від інвентаризації URL до 90-го дня. Автор: [Nicolás Cerón](https://dardo.studio/uk/studio/) ·10 жовтня 2026 р. ![Старе місто за мурами та сучасне місто на протилежних берегах річки вночі, з'єднані кам'яним мостом, де багряна лінія світла веде мандрівників від старої брами до нового міста.](https://dardo.studio/_astro/01M4GYEE19GWZ3941KFH1RTVRX_27BhoE.webp) ## Коротка відповідь Сайт зберігає позиції після міграції, якщо кожен URL, що приносить трафік або посилання, і після запуску відповідає: той самий контент за тією самою адресою або постійний серверний редирект на найближчий відповідник. Більшість проблем із міграцією зводиться до URL, який ніхто не вніс до списку. [Посібник Google із переїзду сайту зі зміною URL](https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes) задає базові правила: зіставити кожен старий URL із новим, використовувати постійні серверні редиректи, як-от 301 або 308, зберігати їх «щонайменше 1 рік» і «очікувати тимчасових коливань позицій сайту під час переїзду». У тому ж посібнику radять змінювати щось одне за раз: спершу новий домен, потім новий дизайн. [Документація Google про зміну адреси](https://support.google.com/webmasters/answer/9370220) категоричніша. Якщо поєднати переїзд зі змінами контенту та структури URL, «ви, імовірно, побачите певну втрату трафіку», поки Google заново оцінює кожну сторінку. Якщо потрібне і те, й інше, плануйте [редизайн](https://dardo.studio/uk/services/website-redesign/) окремим етапом. ## Три види переїзду | Переїзд | Що змінюється | Редиректи | Search Console | | ------------------------------------------------ | ---------------------------------------------- | ------------------------------ | ------------------------------------------------ | | Лише хостинг | Сервери або CDN; усі URL лишаються тими самими | Немає | Стежити за скануванням та індексацією | | Платформа (Wix на WordPress, WordPress на Astro) | CMS, шаблони й зазвичай деякі шаблони URL | Кожен URL, шлях якого змінився | Нова карта сайту, потім моніторинг | | Домен або піддомен | Кожен URL | Усі | Зміна адреси для кожного підтвердженого варіанта | Для переїзду лише хостингу [посібник Google із хостингу](https://developers.google.com/search/docs/crawling-indexing/site-move-no-url-changes) радить зменшити TTL DNS «щонайменше за тиждень до переїзду» і тримати старі сервери ввімкненими, доки їхній трафік не впаде до нуля. Короткий спад частоти сканування після запуску — це нормально. ## Перед переїздом: складіть список усього, що має URL Мапа редиректів настільки добра, наскільки повний список старих URL за нею, а кожне джерело щось пропускає. ### Просканувати чинний сайт Просканувати поточний сайт і вивантажити кожен URL разом із кодом статусу, заголовком, мета-описом, canonical і тегами hreflang, а потім додати всі URL з XML-карти сайту. Google також радить перевірити серверні логи на URL, які нещодавно відвідували принаймні раз. ### Зібрати посадкові сторінки зі Search Console та аналітики У [звіті «Ефективність»](https://support.google.com/webmasters/answer/7576553) Search Console вивантажте вкладку «Сторінки» за найдовший період і зробіть те саме для органічних посадкових сторінок в аналітиці. Ці сторінки приносять трафік і ліди, тому кожну перевіряють вручну під час запуску. ### З'ясувати, хто на вас посилається [Звіт про посилання](https://support.google.com/webmasters/answer/9049606) показує сторінки з найбільшою кількістю посилань, але його таблиці «обмежені 1000 рядками», а Google наголошує, що це не вичерпний список. Поєднайте його з будь-яким інструментом для аналізу зворотних посилань, яким ви користуєтеся. ### Скласти список форм, інтеграцій і медіа Запишіть кожну форму та куди надходять її заявки, кожен вбудований інструмент (бронювання, чат, карти, платежі) і кожен файл, на який посилаються напряму. Посібник Google радить включити до плану «відео, зображення, файли JavaScript і CSS», адже ці URL переїжджають так само, як і решта контенту. ### Створити мапу редиректів Один рядок на кожен старий URL: старий URL, новий URL, код статусу, нотатки, перевірено. Чотири правила: - Зіставляйте кожен старий URL із найближчим відповідником. Редирект багатьох старих URL на одну нерелевантну сторінку, наприклад головну, «може бути сприйнятий як програмна помилка 404». - Якщо кілька старих сторінок об'єднали в одну, перенаправте всі вони на неї. - Якщо сторінка не має відповідника, віддайте їй 404 або 410, а не редирект. - Залишайте шляхи без змін усюди, де це дозволяє нова платформа. ## Під час розробки: редиректи та все, що їх супроводжує ### Використовуйте серверні редиректи 301 або 308 за схемою 1:1 [Документація Google про редиректи](https://developers.google.com/search/docs/crawling-indexing/301-redirects) пояснює, що 301 і 308 сигналізують: «цільова сторінка редиректу має бути канонічною», і рекомендує «постійний серверний редирект, коли це можливо». Тимчасові коди (302, 303, 307) такого сигналу не дають, а редиректи через JavaScript — крайній варіант. Перенаправляйте одразу на кінцевий URL. Сканери Google проходять [до 10 переходів редиректу](https://developers.google.com/crawling/docs/troubleshooting/http-status-codes), проте посібник із переїзду сайту радить «перенаправляти одразу на кінцеве призначення». Якщо після попередньої міграції лишилися редиректи, спрямуйте їх також на нові кінцеві URL. Перевірте, який код стану використовується за замовчуванням там, де обробляються ваші редиректи. У Cloudflare Workers, де Dardo розміщує сайти, які створює, файл \_redirects використовує 302, якщо не вказати 301 у кожному рядку, підтримує до 2000 статичних і 100 динамічних редиректів і не може зіставляти параметри запиту. Тому для простих постійних посилань WordPress (/?p=123) потрібна логіка редиректів у коді Worker. ### Коли замість цього віддавати 404 або 410 Слабкі сторінки, прострочені пропозиції та дублікати не мусять зберігатися. Посібник Google каже, що контент, який ви не переносите, має «коректно повертати HTTP 404 або 410», а сканери Google обробляють кожен код 4xx, окрім 429, однаково: URL зникає з індексу. ### Перенести метадані, canonical і hreflang - **Заголовки та мета-описи.** Переносьте їх поле за полем, а не дозволяйте новим шаблонам генерувати їх. - **Canonical.** Кожна нова сторінка містить canonical на саму себе з новим URL. [Посібник Google із канонізації](https://developers.google.com/search/docs/crawling-indexing/canonicalization) називає canonical «підказкою, а не правилом», тому canonical, редиректи й карта сайту мають узгоджуватися. - **Hreflang.** Згідно з [посібником Google про локалізовані версії](https://developers.google.com/search/docs/specialty/international/localized-versions), кожна мовна версія «має містити посилання на себе та на всі інші мовні версії», а «якщо дві сторінки не вказують одна на одну, теги буде проігноровано». Оновіть кожну анотацію на нові URL. ### Структуровані дані, внутрішні посилання та URL зображень - **Структуровані дані.** Відтворіть розмітку Organization, Breadcrumb, Article або Product у нових шаблонах і перевірте її в Rich Results Test. Посібник Google про переїзд цього не згадує, тож її легко втратити. - **Внутрішні посилання.** Спрямовуйте їх на нові URL, а не на редиректи. - **Зображення та файли.** Зберігайте змістовні назви файлів і alt-тексти, а старі URL зображень і PDF, на які є посилання або трафік із пошуку за зображеннями, перенаправте. ### Аналітика та згода на cookie Знову встановіть аналітику, події конверсій і рекламні пікселі та протестуйте їх на staging. Якщо старий сайт запитував згоду на cookie, новий має запитувати її так само до того, як ці теги спрацюють. ## Що зазвичай ламається на різних платформах Ці нотатки ґрунтуються на документації самих платформ станом на жовтень 2026 року. Вони описують, як працюють платформи, а не їхні дефекти. | Платформа | Шаблони URL для зіставлення | Обмеження експорту та редиректів | | ----------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | WordPress | [Постійні посилання](https://wordpress.org/documentation/article/customize-permalinks/) можуть бути простими (/?p=N), з датою або з назвою запису. Архіви категорій і тегів завжди мають базовий префікс, наприклад /category/. | Починаючи з [WordPress 6.4](https://make.wordpress.org/core/2023/10/16/changes-to-attachment-pages/), сторінки вкладень на нових встановленнях вимкнено, але на оновлених сайтах вони залишаються, тож на старших сайтах може бути по одному URL на кожен завантажений файл. | | Webflow | Елементи CMS розміщуються на сторінках колекцій (Collection pages). | [Експорт коду](https://help.webflow.com/hc/en-us/articles/33961386739347-How-do-I-export-my-Webflow-site-code) не включає вміст CMS, Ecommerce, User Accounts, обробку форм, пошук по сайту та локалізовані сторінки, і потребує тарифу Workspace. Колекції експортуються окремо у форматі CSV. | | Wix | Дописи блогу розташовані за префіксом /post/, який можна перейменувати, але не можна прибрати. У WordPress його зберігає власна структура постійних посилань /post/%postname%/. | Сайт на Wix [«має працювати на серверах Wix»](https://support.wix.com/en/article/exporting-or-embedding-your-wix-site-elsewhere), тож перехід означає перебудову сторінок. | | Framer | Зміна підшляху [не оновлює наявні правила редиректів](https://www.framer.com/help/articles/how-to-setup-redirects-to-maintain-seo-ranking/), тому старі правила можуть вести на неіснуючі шляхи. | Сайти публікуються як стандартні HTML, CSS і JavaScript; [вміст CMS експортується через плагіни](https://www.framer.com/help/articles/porting-your-data-from-framer/) у CSV або JSON. | | Squarespace | [Зіставлення URL](https://support.squarespace.com/hc/en-us/articles/205815308-URL-mappings) приймають змінну \[name\] для цілих колекцій, наприклад /blog/\[name\] -> /posts/\[name\] 301. | [Експорт](https://support.squarespace.com/hc/en-us/articles/206566687-Exporting-your-site) — це WordPress XML з однією сторінкою блогу, сторінками макетів і галереями, але без сторінок магазину, блоків товарів, відео чи аудіо та власного CSS. Зіставлення URL не можуть перенаправляти URL зображень чи файлів і вміщують близько 2500 рядків. | | Shopify | URL вітрини розміщені за шляхами на кшталт /products/, /collections/, /pages/ і [/blogs//](https://shopify.dev/docs/api/liquid/objects/blog); Shopify вважає /products і /collections фіксованими. | [Редиректи](https://help.shopify.com/en/manual/online-store/menus-and-links/url-redirect) працюють лише з URL, які більше не завантажують сторінку, а максимум для магазину — 100 000 (20 000 000 на Plus). | Перехід із Wix означає перебудову кожної сторінки; перехід зі Squarespace — імпорт того, що охоплює експорт, і перебудову решти. Перехід на Shopify зазвичай змінює URL товарів, тож мапа має охоплювати кожен товар. ## День запуску 1. **DNS.** Якщо змінюється хостинг або DNS, зменште TTL щонайменше за тиждень наперед. 2. **Блокування сканування.** Приберіть теги `noindex` зі staging і блокування в robots.txt. Google радить скласти список усіх URL, де ви використовували `noindex` під час розробки. 3. **Редиректи.** Випускайте їх в одному релізі з новим сайтом. 4. **Перевірка редиректів.** Проженіть усю мапу скриптом: кожен старий URL повертає 301 або 308 на правильний кінцевий URL за один крок, а цей URL повертає 200. 5. **Search Console.** Підтвердіть новий сайт і надішліть нову мапу сайту, а також мапу старих URL, щоб їх просканували повторно. Попередження про те, що ці URL перенаправляються, — очікувані. 6. **Change of Address.** Для зміни домену подайте її з ресурсу, яким ви володієте з обох боків, тим самим акаунтом Google, для кожного варіанту старого домену, зокрема з www і без www. 7. **Ключові сценарії.** Надішліть справжню форму, проведіть тестовий платіж і переконайтеся, що події аналітики надходять. 8. **Ваші власні посилання.** Оновіть [профілі в соцмережах, рекламу та записи в каталогах](https://dardo.studio/uk/blog/brand-launch-checklist/). ## 30, 60 і 90 днів після запуску ### Дні 1–30: чекайте змін Позиції можуть коливатися, «поки Google повторно сканує й переіндексує ваш сайт», а «невеликому чи середньому сайту потрібно кілька тижнів, щоб більшість сторінок змістилися, великим — довше». Стежте за: - **Звітами про індексацію та мапу сайту.** Кількість індексованих URL на старому сайті падає, а на новому зростає. - **Ефективністю за сторінками.** Нові URL починають отримувати покази та кліки. - **Логами сервера та помилками 404.** Кожна несподівана 404 — це відсутній рядок у мапі. Перевіряйте щодня протягом двох тижнів. ### Дні 31–60: порівняйте з базовим рівнем Порівняйте найпопулярніші цільові сторінки з їхніми новими URL. Для кожної сторінки, що втратила кліки, перевірте по черзі: чи редирект веде на правильну сторінку за один крок, чи змінилися контент або заголовок, чи внутрішні посилання досі ведуть на неї, чи вона є в мапі сайту. Потім попросіть сайти, що дають найцінніші зворотні посилання, оновити їх. ### День 90 і далі: залишайте редиректи Посібник Google радить зберігати редиректи «зазвичай щонайменше 1 рік», а з погляду користувачів — «розглянути можливість зберігати редиректи безстроково». Для переїзду домену сторінка Change of Address встановлює мінімум у 180 днів, після чого Google вважає старий сайт непов'язаним, якщо він і далі доступний для сканування. Також радить оплачувати старий домен «щонайменше рік», щоб ніхто інший його не купив. ## Чекліст | Етап | Завдання | Готово, коли | | ------------- | ------------------------------------------------------------------------- | ------------------------------------------------------------------------------ | | До запуску | Просканувати сайт, мапу сайту та логи сервера | Є єдиний список усіх старих URL із кодами статусу | | До запуску | Експортувати цільові сторінки та сторінки з найбільшою кількістю посилань | Топові сторінки та цілі зворотних посилань позначені в мапі | | До запуску | Скласти список форм, інтеграцій, скриптів і файлів | Для кожного є відповідальний і план на новому сайті | | До запуску | Побудувати мапу редиректів | Для кожного старого URL є ціль або рішення щодо 404/410 | | Розробка | Серверні редиректи 301 або 308 | Один крок, без ланцюжків і масових редиректів на головну | | Розробка | Title, description, canonical, hreflang | Збігаються зі старими сторінками; canonical і hreflang використовують нові URL | | Розробка | Структуровані дані, внутрішні посилання, URL зображень | Rich Results Test пройдено; жодне внутрішнє посилання не веде на редирект | | Розробка | Аналітика, конверсії та згода на cookie | Події спрацьовують на staging, а де потрібно — лише після згоди | | Запуск | Прибрати noindex і блокування в robots.txt | Нові URL доступні для сканування | | Запуск | Протестувати мапу редиректів | Кожен рядок повертає очікуваний код і ціль | | Запуск | Search Console: підтвердження, мапи сайту, Change of Address | Надіслано без критичних помилок | | Після запуску | Стежити за індексацією, 404 і ефективністю | Старі URL випадають, нові отримують покази | | Після | Залиште редиректи та старий домен | Щонайменше один рік | ## Допомога з міграцією Dardo переносить сайти на індивідуальні збірки на Astro з Cloudflare Workers, а мапа редиректів — це результат роботи, який ми тестуємо до запуску й передаємо разом із сайтом. Дивіться [міграцію сайту](https://dardo.studio/uk/services/website-migration/) або [редизайн сайту](https://dardo.studio/uk/services/website-redesign/), якщо разом із переїздом потрібен новий дизайн. Або [розкажіть, що ви переносите](https://dardo.studio/uk/contact/). [Nicolás Cerón](https://dardo.studio/uk/studio/) Nicolás Cerón — засновник Dardo, студії брендингу, веб-дизайну та розробки в Боготі, Колумбія. ## Продовжуйте знайомство. - [Послуга · **Міграція сайту без втрати SEO-позицій**](https://dardo.studio/uk/services/website-migration/) - [Ваш проєкт · **Почати розмову**](https://dardo.studio/uk/contact/)