# SEO-чекліст міграції сайту

Шаблон MAX SITE · версія 07.09.2026

Для перенесення сайту на інший хостинг, CMS або домен. Заповніть відповідальних, результати перевірок і посилання на докази. Позначка «готово» означає пройдений тест, а не лише наявний файл конфігурації. Це робочий план, не гарантія збереження позицій.

## 1. Зафіксувати межі й вихідний стан

- [ ] Власник релізу: __________; технічний виконавець: __________; час запуску: __________.
- [ ] Тип зміни: лише хостинг / CMS без зміни URL / структура URL / домен.
- [ ] Перелік змін і погодження: __________. Не поєднувати перенесення платформи з масовою зміною контенту й адрес без окремого плану.
- [ ] Зберегти резервну копію сайту, бази даних, медіа, поточного релізу та DNS-записів. Перевірити відновлення; записати ідентифікатор попереднього релізу: __________.
- [ ] Експортувати Search Console та аналітику за доступний репрезентативний період: запити, сторінки, країни, пристрої, конверсії. Зберегти фільтри й дати; не включати персональні дані.
- [ ] Зібрати URL із sitemap, crawl, аналітики та зовнішніх посилань. Включити важливі файли й зображення, не лише HTML.

## 2. Узгодити карту адрес

| Стара адреса | Нова адреса | Дія | Підстава | Очікуваний HTTP | Тест / відповідальний |
|---|---|---|---|---|---|
| Заповнити | Заповнити | Зберегти / перенаправити / видалити | Намір, трафік, посилання | 200 / 301 / 404 / 410 | Заповнити |

- [ ] Якщо змінюється тільки хостинг, усі публічні адреси залишаються 1:1.
- [ ] Для змінених адрес налаштувати серверне постійне перенаправлення прямо на релевантну кінцеву сторінку; перевірити відсутність циклів і ланцюжків.
- [ ] Не перенаправляти всі видалені сторінки на головну. Об’єднання має відповідати змісту; для відсутньої заміни — справжній 404/410.
- [ ] Оновити внутрішні посилання, canonical, hreflang (якщо використовується) і sitemap. Ціль перенаправлення має відповідати 200.
- [ ] Для міграції зі зміною URL запланувати збереження перенаправлень щонайменше на рік, бажано довше.

Орієнтир: [Google — переїзд зі зміною URL](https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes).

## 3. Перевірити нове середовище до перемикання

- [ ] Preview захищено автентифікацією або має noindex. Якщо покладаєтеся на noindex, robots.txt не повинен заважати пошуковику прочитати цю директиву.
- [ ] На майбутніх production-сторінках підготовлено правильний режим індексації; тестові адреси не потрапляють у canonical або sitemap.
- [ ] Порівняти старі й нові Title, H1, Description, головний контент, schema та статуси всіх важливих URL; кожна відмінність пояснена.
- [ ] Перевірити сертифікат, основний домен, www/non-www, HTTP/HTTPS, /index.html та справжню 404.
- [ ] Зображення, шрифти, CSS і JavaScript доступні. Немає змішаного HTTP-контенту чи заблокованих ресурсів.
- [ ] Форми: підтверджена доставка, відмова сервера, тайм-аут, повтор, резервний контакт. Конверсія виникає лише після підтвердження успіху.
- [ ] Перевірити телефон, меню, Telegram, consent і аналітику на телефоні та комп’ютері; секрети й контакти заявників не йдуть в аналітичні події.
- [ ] Порівняти швидкість у однакових умовах. Зберегти мобільні й desktop-скріншоти, журнал тестів та список відкритих ризиків.

## 4. Запуск і перевірка ззовні

- [ ] Погодити DNS-перемикання; зберегти записи для відкату. Старий хостинг не вимикати, поки трафік не перейшов і новий не перевірено.
- [ ] Після перемикання перевірити сайт із зовнішньої мережі, а не тільки localhost. Перевірити HTTPS, основні URL, sitemap, robots, форми й отримання подій.
- [ ] Зняти лише preview-обмеження, які випадково успадкував production; не видаляти обґрунтований noindex службових сторінок.
- [ ] Перевірити володіння ресурсом Search Console та подати актуальний sitemap. «Зміна адреси» потрібна для підтримуваного переїзду на інший домен/субдомен, не для простої зміни хостингу.
- [ ] Зафіксувати час, реліз, результати crawl, статуси та відповідального за подальше спостереження.

Орієнтир: [Google — зміна хостингу без зміни URL](https://developers.google.com/search/docs/crawling-indexing/site-move-no-url-changes).

## 5. Умови зупинки й відкат

- [ ] Не запускати за масових 404/5xx, помилкових canonical/noindex, несправних форм, витоку даних або недоступного HTTPS.
- [ ] У разі критичної помилки повернути перевірений попередній реліз і, за потреби, збережені DNS-записи. Врахувати кешування DNS і перевірити обидва середовища.
- [ ] Не відновлювати стару базу поверх нових заявок без узгодження: спочатку зберегти нові дані.
- [ ] Записати причину, час, вплив, виконані дії й результати повторної перевірки. Не вважати тимчасове коливання позицій самостійною підставою хаотично змінювати URL.

## 6. Контроль після запуску

| Точка контролю | Що перевірити | Факт / доказ | Наступна дія / власник |
|---|---|---|---|
| Одразу | HTTPS, URL, redirects, форми, аналітика |  |  |
| День 2 | 404/5xx, sitemap, Googlebot, canonical/noindex |  |  |
| День 7 | Індексація, запити → сторінки, ліди, CWV за наявності даних |  |  |
| День 14 | Динаміка кластерів, помилки обходу, старий/новий трафік |  |  |
| День 30 | Порівняння з baseline, відкриті ризики, наступний план |  |  |

Порівнюйте однакові країни, пристрої, тип пошуку та періоди з урахуванням сезонності. Дані GSC і польові CWV надходять із затримкою; успішний лабораторний тест не доводить стабільних польових показників або зростання позицій.

Допомога з перевіркою: [MAX SITE — технічне SEO](https://maxsite.com.ua/tehnichne-seo/) · [контакти](https://maxsite.com.ua/kontakty/).