Аудит сайта перед миграцией - это инвентаризация контента, SEO-сигналов и технической конфигурации текущего сайта до начала переезда на новый стек. Он занимает один сфокусированный рабочий день и предотвращает самые дорогие ошибки миграции: потерянные URL, обнуленные позиции в поиске и незамеченную кастомную функциональность, которая перестает работать в день запуска.
Большинство провалов миграции сайта не связаны со стеком, на который переезжает компания. Они связаны с тем, что команда пропустила этот шаг: увидела медленный WordPress или неудобную Tilda и сразу перешла к «давайте пересоберем на Astro», не описав сначала, что именно есть на старом сайте. В интеграционных проектах Exceltic.dev мы регулярно видим один и тот же сценарий: через месяц после запуска нового сайта заказчик обнаруживает, что форма обратной связи больше никуда не отправляет заявки, потому что интеграция с CRM была зашита в старую тему и про нее никто не вспомнил на этапе планирования. Дальше в статье - что именно инвентаризировать, в каком порядке и как уложить весь аудит в один день.
Зачем аудит нужен именно перед переездом
Аудит нужен потому, что миграция сайта - это не косметическое обновление дизайна, а замена инфраструктуры, на которой держится весь накопленный SEO-вес и весь работающий функционал. Без предварительной фиксации того, что есть сейчас, невозможно доказать после переезда, что ничего не потеряно.
Три категории риска, которые аудит закрывает:
- Потеря URL. Если не выгружен полный список адресов старого сайта, часть страниц просто не попадет в карту редиректов - и по ним начнут падать 404-ошибки, которые видит и пользователь, и поисковый робот.
- Потеря SEO-сигналов. Позиции, обратные ссылки, метатеги и структурированные данные накапливались годами. Без снимка «до» невозможно позже доказать, что переезд не обвалил трафик, и невозможно быстро найти причину, если обвалил.
- Потеря кастомной функциональности. Формы, интеграции с CRM, калькуляторы, виджеты бронирования - все это часто держится на плагинах или самописном коде, который не виден в дизайне и о котором вспоминают только когда он перестает работать.
Аудит сайта: формализованная инвентаризация контента, SEO-показателей и технических интеграций текущего сайта, зафиксированная до начала любых работ по миграции.
Если компания уже определилась с переездом, разумно совмещать аудит с планированием самого проекта - подробнее о том, как устроен переезд сайта на новый стек в Exceltic.dev, мы разбирали отдельно.
Контент - что инвентаризировать
Первый блок аудита отвечает на вопрос: что именно физически существует на сайте сейчас, до того как это будет пересобрано на новой платформе.
Чек-лист по контенту:
- Полный список страниц и постов с URL. Экспорт всех записей: страницы, посты блога, товары, лендинги - вместе с точным адресом каждой. Для WordPress это делается через экспорт XML или прямой запрос к базе; для Tilda и Wix - через карту сайта и ручной обход, потому что нативного экспорта URL там часто нет.
- Объем медиабиблиотеки. Сколько изображений, документов, видео хранится на сайте, в каком формате и какого суммарного веса. Это определяет, сколько времени займет перенос медиа и нужно ли сразу закладывать оптимизацию форматов (WebP, AVIF) на новом стеке.
- Кастомные типы записей. Если на WordPress используются custom post types (кейсы, вакансии, отзывы, FAQ как отдельный тип) - их нужно явно выписать, потому что при поверхностной миграции они обычно вообще не экспортируются вместе со стандартными постами.
- Формы и их назначения. Каждая форма на сайте отправляет данные куда-то: на email, в CRM через webhook, в Google Sheets. Нужно зафиксировать не только сам факт наличия формы, но и точный маршрут данных - это самая частая точка разрыва при переезде.
Результат этого блока - таблица: URL, тип контента, есть ли форма или интеграция на странице, дата последнего обновления. Это база для мэппинга редиректов на следующем этапе проекта.
SEO-сигналы - что зафиксировать до переезда
Второй блок фиксирует состояние поисковой видимости сайта на момент «до», чтобы после переезда было с чем сравнивать и что защищать.
Позиции по коммерческим ключевым запросам. Выгрузите текущие позиции по 15-30 ключевым фразам, которые реально приносят заявки - не по всем словам подряд, а по тем, что связаны с деньгами. Это делается через Google Search Console (раздел Efficiency, отчет по запросам) или через любой трекер позиций.
Снимок профиля обратных ссылок. Экспортируйте список доменов, ссылающихся на сайт, через Google Search Console (Links) или сторонний сервис. После переезда сравнение этого снимка с новым состоянием сразу покажет, если редиректы настроены неправильно и внешние ссылки начали вести на 404.
Существующие meta title и meta description. Выгрузите их постранично - вручную через просмотр исходного кода для небольших сайтов, через SEO-плагин (Yoast, RankMath) для WordPress с большим числом страниц. Это готовый черновик для нового сайта, который экономит недели работы копирайтера.
Используемая структурированная разметка. Проверьте, какие типы Schema.org уже установлены: Article, Product, FAQPage, BreadcrumbList, Organization. Их нужно воспроизвести на новом стеке - Google не будет показывать расширенные сниппеты, если разметка исчезнет даже на короткий период.
Содержимое robots.txt и sitemap.xml. Сохраните оба файла как есть. В robots.txt часто накапливаются исключения, добавленные вручную несколько лет назад по забытой причине - если их не перенести осознанно, можно случайно закрыть от индексации важные разделы нового сайта.
Технический аудит
Третий блок фиксирует техническое состояние сайта - то, с чем предстоит сравнивать производительность нового стека и что нужно воспроизвести функционально.
Текущие показатели PageSpeed и Core Web Vitals. Снимите baseline через PageSpeed Insights для трех-пяти ключевых страниц: главная, посадочная страница с максимальным трафиком, карточка товара или услуги. Зафиксируйте LCP, CLS и INP отдельно для мобильной и десктопной версии - без этого снимка любое обсуждение «стало быстрее» после переезда останется голословным.
Сторонние скрипты и интеграции. Выпишите все внешние скрипты, подключенные на сайте: аналитику, чаты, пиксели рекламных кабинетов, виджеты бронирования. Каждый такой скрипт - это либо готовая интеграция, которую нужно перенести один в один, либо повод пересмотреть, нужна ли она вообще на новом стеке.
Плагины и кастомный код с нестандартной функциональностью. Отдельно выделите то, что не относится к дизайну: плагины расчета доставки, калькуляторы стоимости, интеграции с 1С или складскими системами. Именно они чаще всего не документированы и держатся на памяти одного разработчика, который может быть уже недоступен к моменту переезда.
Настройка аналитики и трекинга. Зафиксируйте, какие цели и события настроены в Google Analytics или Яндекс.Метрике, какие конверсии передаются в рекламные кабинеты. Без этого снимка после переезда легко потерять историю конверсий или получить разрыв в отчетности ровно в день запуска.
Пошаговый чек-лист на один день
Весь аудит укладывается в восемь рабочих часов при условии, что в команде есть доступ к админке сайта, Google Search Console и хотя бы один человек, знающий текущую CMS.
Час 1-2: экспорт контента
Выгрузите полный список URL, медиабиблиотеку и кастомные типы записей. Для WordPress используйте встроенный экспорт XML или прямой SQL-запрос к таблице wp_posts; для Tilda и Wix - обход через карту сайта и ручную фиксацию в таблицу.
Пример SQL-запроса для выгрузки всех опубликованных URL из WordPress
SELECT ID, post_title, post_type, guid, post_modified
FROM wp_posts
WHERE post_status = 'publish'
ORDER BY post_type, post_modified DESC;Час 3-4: снимок SEO-сигналов
Выгрузите позиции по ключевым запросам, экспортируйте профиль обратных ссылок из Search Console, соберите meta title и description постранично, сохраните robots.txt и sitemap.xml в отдельную папку с датой снимка.
Час 5-6: технический инвентарь
Снимите PageSpeed и Core Web Vitals для ключевых страниц, выпишите все сторонние скрипты через просмотр исходного кода или Tag Assistant, задокументируйте нестандартные плагины и кастомный код.
Час 7: формы и интеграции
Протестируйте каждую форму на сайте, зафиксируйте, куда именно уходят данные - это единственный пункт чек-листа, который нельзя сделать по документации, только руками, отправив тестовую заявку и проверив, куда она пришла.
Час 8: согласование со стейкхолдерами
Соберите результаты в один документ и покажите его всем, кто отвечает за маркетинг, продажи и IT на стороне заказчика. Задача этого часа - получить подтверждение, что ничего важного не пропущено, до того как команда начнет проектировать новый сайт.
Что будет, если пропустить аудит
Пропуск аудита не экономит день - он переносит те же самые часы работы на период после запуска, когда цена ошибки уже другая.
Сломанные редиректы. Без карты URL часть страниц старого сайта останется без редиректа. Пользователи и поисковые роботы упираются в 404, внешние ссылки с других сайтов начинают вести в никуда, накопленный годами ссылочный вес обнуляется.
Падение позиций. Без снимка meta-тегов и структурированных данных «до» переезда новый сайт запускается с пустыми или дублирующими метатегами. Восстановление позиций после такого падения занимает от двух до шести месяцев - и это в лучшем случае, если причина вообще будет найдена быстро.
Обнаруженные постфактум формы и интеграции. Самый частый и самый дорогой сценарий: через одну-две недели после запуска отдел продаж замечает, что заявки перестали приходить в CRM. Форма на новом сайте выглядит идентично старой, но webhook, отправлявший данные, не был перенесен, потому что о нем никто не знал. За эти недели теряются реальные лиды, а не абстрактный трафик.
Для кого этот чек-лист
Этот чек-лист подходит любой компании, планирующей переезд сайта - независимо от того, с какой платформы уходят и на какую переезжают. WordPress, Tilda, Wix, Webflow в качестве исходной точки и Astro, Next.js или другой headless-стек в качестве цели - принцип инвентаризации не меняется.
Особенно критичен аудит для компаний, у которых сайт - не просто визитка, а рабочий инструмент продаж: с формами, интеграциями в CRM, накопленной историей публикаций и заметным органическим трафиком. Чем больше у сайта лет истории и подключенных сервисов, тем дороже цена пропущенного пункта в чек-листе.
Часто задаваемые вопросы
Сколько на самом деле занимает аудит сайта перед миграцией?
При наличии доступа к админке, Google Search Console и человеку, знающему текущую CMS, полный аудит занимает один рабочий день - около восьми часов. Для сайтов с нестандартной архитектурой, большим числом кастомных интеграций или отсутствием документации срок может увеличиться до двух-трех дней. Экономить на этом этапе не стоит: каждый непроверенный пункт переносится в проблему после запуска, где стоит уже недели, а не часы.
Можно ли делать аудит своими силами без привлечения агентства?
Технически да, если в команде есть человек, знакомый с текущей CMS и с базовыми SEO-инструментами вроде Google Search Console. Сложность в том, что аудит требует одновременно контентного, SEO- и технического взгляда - редко все три компетенции есть у одного специалиста. Для небольших сайтов без сложных интеграций самостоятельный аудит по этому чек-листу вполне реалистичен.
Что делать, если в процессе аудита нашли форму без понятного назначения?
Отправьте через нее тестовую заявку с пометкой «тест» и проверьте все возможные точки назначения: почтовый ящик, привязанную CRM, интеграционные сервисы вроде Zapier или Make, таблицы Google Sheets. Если маршрут так и не удалось восстановить, зафиксируйте форму как «требует уточнения у предыдущего разработчика» и не удаляйте старую версию сайта до полного выяснения - это единственная страховка в такой ситуации.
Нужно ли повторять аудит, если сайт уже мигрировали, но что-то пошло не так?
Да, и в этом случае аудит еще важнее, потому что он выполняет диагностическую функцию: сравнение текущего состояния с состоянием до переезда быстро показывает, что именно потерялось - конкретные URL без редиректа, пропавшие метатеги, отключенные интеграции. Без снимка «до» такой пост-фактум аудит превращается в догадки вместо точного диагноза.
Что делать дальше
- Начните с экспорта полного списка URL - это основа для карты редиректов и самый частый источник потерь при спешке.
- Снимите SEO-baseline до, а не после переезда - без него невозможно доказать ни падение, ни рост трафика.
- Проверьте каждую форму руками, отправив тестовую заявку - это единственный надежный способ найти скрытые интеграции.
- Зафиксируйте результат в одном документе и согласуйте со всеми стейкхолдерами до начала разработки нового сайта.
Если вы планируете переезд и хотите, чтобы аудит и сама миграция прошли без потери позиций и функциональности - опишите команде Exceltic.dev текущий стек и объем сайта. Разберем архитектуру и оценим объем работ. Для сайтов, которые уже переехали и требуют регулярной технической поддержки, у нас есть отдельный формат сопровождения после запуска.