Сайт приносит деньги с РСЯ или AdSense: как подготовить его к переезду на новый сервер

Если сайт зарабатывает на РСЯ, AdSense или другой рекламной сети, переезд на новый сервер нельзя делать как обычный перенос файлов. Для такого проекта важен не сам факт миграции, а защита дохода: чтобы реклама продолжала показываться, рекламные роботы могли читать страницы, ads.txt был доступен, сайт не отдавал 500/502/404, а поисковый трафик не просел из-за технической ошибки.

Главная ошибка владельцев доходных сайтов — относиться к переезду как к технической задаче “скопировать файлы и базу”. Для сайта с рекламной монетизацией это финансовая операция. Если сайт недоступен несколько часов, если рекламный crawler получает ошибки, если ads.txt пропал или robots.txt случайно закрыл нужного робота, доход может просесть быстрее, чем вы успеете понять причину.

Эта инструкция не про “какой VPS выбрать”. Она про то, как подготовить сайт к переезду на новый сервер так, чтобы не потерять показы рекламы, доход, индексацию, доступность и доверие рекламных систем.

Почему переезд доходного сайта опаснее обычной миграции

Обычный сайт можно перенести ночью, проверить главную страницу и считать задачу закрытой. Сайт с РСЯ или AdSense так переносить нельзя. У него больше критичных точек:

• рекламные блоки должны продолжать загружаться;
• страницы должны быть доступны рекламным роботам;
• ads.txt должен открываться из корня домена;
• robots.txt не должен блокировать рекламных и поисковых роботов;
• HTTPS должен работать без ошибок;
• редиректы должны быть такими же, как до переезда;
• страницы с трафиком не должны отдавать 404, 500, 502 или 504;
• CDN, WAF и firewall не должны блокировать AdSense, YandexDirect, YandexBot, Googlebot и другие нужные crawler-и;
• старый сервер нельзя выключать сразу после смены DNS;
• нужно сравнивать доход, RPM, показы, coverage и ошибки до и после миграции.

Если сайт приносит деньги каждый день, даже короткий простой может стоить дороже, чем нормальная подготовка миграции.

Главный принцип: сначала защитить доход, потом переносить сайт

У доходного сайта цель миграции — не “переехать на новый сервер”. Цель — переехать так, чтобы пользователь, поисковый робот и рекламный робот не заметили технического сбоя.

Правильная логика:

• сначала собрать текущие метрики;
• сначала проверить рекламные блоки и ads.txt;
• сначала снизить DNS TTL;
• сначала развернуть копию сайта на новом сервере;
• сначала проверить все критичные URL;
• сначала убедиться, что новый сервер не блокирует роботов;
• только потом переключать DNS;
• после переключения не выключать старый сервер сразу;
• первые дни смотреть доход, ошибки, логи и crawlability.

Если вы переносите сайт, который уже зарабатывает, спешка почти всегда дороже аккуратной подготовки.

Что зафиксировать до переезда

Перед миграцией нужно снять базовую картину. Иначе после переезда вы не поймете, просел доход из-за сервера, сезонности, аукциона, трафика, рекламной сети или случайного технического сбоя.

Зафиксируйте за 3-7 дней до переезда:

• средний доход в день;
• количество показов рекламы;
• RPM/CPM;
• CTR;
• coverage/fill rate, если доступно;
• количество страниц с рекламой;
• топ-20 страниц по доходу;
• топ-20 страниц по трафику;
• источники трафика;
• среднее время ответа сервера;
• ошибки 4xx и 5xx;
• состояние ads.txt;
• robots.txt;
• sitemap.xml;
• текущие DNS-записи;
• текущий IP сервера;
• настройки CDN/WAF, если используется Cloudflare или аналог.

Это скучная работа, но без нее вы будете гадать. Если доход упал на 30% после переезда, нужно понимать: упал трафик, пропали показы, рекламный crawler не видит страницы, ads.txt недоступен или просто изменился рекламный аукцион.

Проверьте ads.txt до миграции

Для сайта с рекламной монетизацией ads.txt — один из самых важных файлов. Он должен открываться из корня домена:

https://example.com/ads.txt

Проверьте до переезда:

• файл открывается по HTTPS;
• файл находится именно в корне домена;
• сервер отдает HTTP 200 OK;
• нет редиректа на странную страницу;
• нет 404;
• нет 403;
• нет 500;
• в файле есть строки AdSense, РСЯ и других используемых сетей;
• строки не повреждены при копировании;
• файл доступен без авторизации;
• файл не закрыт robots.txt;
• файл доступен и с www, и без www через правильный редирект.

Частая ошибка при переезде: сайт перенесли, а ads.txt забыли. Визуально сайт работает, страницы открываются, реклама иногда еще показывается, но рекламная система при следующей проверке видит проблему. Для владельца это выглядит как “доход почему-то просел”.

Проверьте robots.txt

robots.txt может случайно сломать доход. Особенно если на новом сервере включили тестовый robots.txt с запретом индексации или скопировали staging-конфиг.

Проверьте:

• robots.txt доступен по адресу https://example.com/robots.txt;
• нет строки Disallow: / для всех роботов;
• не заблокированы Googlebot и YandexBot;
• не заблокирован рекламный робот РСЯ YandexDirect;
• не заблокирован доступ к страницам с рекламой;
• не заблокирован ads.txt;
• sitemap указан корректно;
• нет временных правил от staging-сайта;
• нет разных robots.txt на www и non-www с конфликтами.

Особенно опасна ситуация, когда сайт на тестовом домене был закрыт от индексации, а потом этот robots.txt уехал в production. Владелец видит работающий сайт, но роботы получают запрет.

Проверьте рекламные блоки

Перед миграцией нужно сохранить не только файлы сайта, но и рекламную интеграцию.

Проверьте:

• код AdSense не изменен;
• код РСЯ не изменен;
• рекламные блоки не удалены шаблоном темы;
• вставки в header/footer сохранились;
• плагины рекламы перенесены;
• виджеты рекламы перенесены;
• shortcode-блоки работают;
• AMP-страницы, если используются, показывают корректную рекламу;
• мобильная версия сайта не потеряла блоки;
• не включился adblock на уровне сервера, CDN или security-плагина;
• consent/CMP-баннер работает, если сайт использует consent mode или GDPR-сценарии.

Нельзя проверять только главную страницу. Доход часто дают конкретные статьи, категории, мобильные страницы или старые материалы из поиска. Проверяйте именно страницы, которые приносят трафик и деньги.

Составьте список денежных URL

Перед переносом составьте список страниц, которые нельзя сломать. Это не обязательно весь сайт. Обычно достаточно топовых URL.

В список должны войти:

• топ-20 страниц по доходу;
• топ-20 страниц по трафику;
• страницы с максимальным RPM;
• страницы, где больше всего рекламных показов;
• главная страница;
• ключевые категории;
• страницы из Google Search Console с большим трафиком;
• страницы из Яндекс Вебмастера с большим трафиком;
• страницы, которые часто заходят из социальных сетей или Дзена;
• страницы, где реклама вставлена нестандартно.

После переноса именно эти URL нужно проверять первыми. Не главную страницу и не “сайт вроде работает”, а деньги.

Снизьте DNS TTL заранее

DNS TTL нужно снижать не в момент переезда, а заранее. Иначе часть пользователей и роботов еще долго будет попадать на старый сервер, а часть уже на новый.

Практический порядок:

• за 24-72 часа до миграции снизить TTL для A/AAAA/CNAME-записей;
• обычно удобно ставить 300 секунд;
• дождаться, пока старый TTL протухнет у резолверов;
• только потом переключать IP;
• после стабильной работы 2-3 дня вернуть TTL к нормальному значению.

Если домен обслуживается через Cloudflare или другой DNS/CDN, проверьте реальные записи и режим проксирования. Ошибка в DNS может отправить пользователей не туда, даже если сам сайт перенесен идеально.

Не выключайте старый сервер сразу

Одна из самых дорогих ошибок — переключить DNS и сразу удалить старый сервер. Так делать нельзя.

После смены DNS часть пользователей, провайдеров, crawler-ов и рекламных систем может еще обращаться к старому IP. Если старый сервер выключен, они получат ошибку. Для обычного сайта это неприятно. Для сайта с рекламой это потеря показов, crawler errors и возможное снижение дохода.

Практический минимум:

• держать старый сервер включенным 48-72 часа после переключения;
• если сайт большой и доходный — держать 5-7 дней;
• поставить на старом сервере режим read-only, если есть комментарии или пользовательский контент;
• не принимать новые данные на старый сервер после финальной синхронизации;
• логировать обращения к старому IP;
• выключать старый сервер только когда трафик на него почти исчез.

Если на сайте есть комментарии, формы, личные кабинеты или платежи, нужно отдельно продумать финальную синхронизацию базы. Иначе часть данных останется на старом сервере.

Проверьте новый сервер до переключения DNS

До смены DNS сайт должен быть полностью проверен на новом сервере. Не “после переключим и посмотрим”, а до переключения.

Проверять можно через hosts-файл на своем компьютере. Так вы открываете домен на новом IP, не меняя DNS для всех пользователей.

Проверьте:

• главная страница открывается;
• денежные URL открываются;
• страницы отдают HTTP 200;
• редиректы совпадают со старым сервером;
• HTTPS работает;
• сертификат выпущен на правильный домен;
• www/non-www работает так же, как раньше;
• HTTP редиректит на HTTPS;
• robots.txt совпадает с production-версией;
• ads.txt доступен;
• sitemap.xml доступен;
• рекламные блоки есть в HTML;
• CSS/JS не отдают 404;
• картинки загружаются;
• мобильная версия работает;
• кэш не показывает старую тестовую версию;
• админка сайта работает;
• логин работает;
• формы работают;
• нет массовых ошибок в логах.

Если новый сервер не прошел проверку, DNS переключать нельзя.

Проверьте HTTP-статусы

Для рекламной монетизации важно, чтобы страницы и служебные файлы отдавали правильные статусы.

Минимальная проверка:

• / — 200 или правильный редирект;
• /robots.txt — 200;
• /ads.txt — 200;
• /sitemap.xml — 200 или правильный индекс sitemap;
• денежные статьи — 200;
• категории — 200;
• старые URL — 200 или правильный 301;
• битые URL — честный 404, а не soft 404;
• нет массовых 500/502/503/504.

Особенно внимательно проверьте ads.txt. Если содержимое файла видно в браузере, но сервер отдает неправильный HTTP-статус, рекламная система может не принять файл.

Проверьте HTTPS и редиректы

После миграции часто ломаются редиректы. Например, раньше сайт работал на https://www.example.com, а после переноса открывается https://example.com. Или HTTP не редиректит на HTTPS. Или появляется цепочка из нескольких редиректов.

Проверьте варианты:

• http://example.com
• https://example.com
• http://www.example.com
• https://www.example.com
• https://example.com/ads.txt
• https://www.example.com/ads.txt
• старые URL из поиска;
• страницы с UTM-метками;
• AMP-страницы, если используются.

Правильный результат: все версии приводят к основной версии сайта без лишних циклов, ошибок и потери пути URL.

Проверьте CDN, Cloudflare и WAF

CDN и WAF часто ломают миграции не хуже плохого сервера. Сайт в браузере может открываться, а рекламный робот получать 403, challenge, капчу или пустую страницу.

Перед переключением проверьте:

• не включен ли агрессивный Bot Fight Mode;
• не блокируются ли Googlebot, Mediapartners-Google, YandexBot, YandexDirect;
• не включена ли капча для подозрительных стран;
• не закрыт ли доступ к ads.txt;
• не кэшируется ли старый robots.txt;
• не кэшируется ли старая версия рекламного кода;
• не включен ли firewall rule по User-Agent;
• не блокируются ли HEAD-запросы;
• не ломается ли HTTPS между CDN и origin;
• origin IP нового сервера прописан правильно.

Очень частый сценарий: владелец включает защиту от ботов, а вместе с мусорными ботами режет рекламных и поисковых роботов. Доход падает, потому что система не может нормально сканировать страницы или ads.txt.

Не меняйте дизайн и сервер одновременно

Переезд сервера — уже риск. Не надо одновременно менять тему WordPress, рекламные блоки, структуру URL, CDN, кеширующий плагин, PHP-версию, домен, шаблон и расположение рекламы.

Правильное правило:

• сначала перенести сайт без изменений;
• стабилизировать работу;
• сравнить доход и ошибки;
• только потом менять дизайн, рекламу или оптимизацию.

Если после одновременной смены сервера, темы и рекламы доход упал, вы не поймете причину. Это плохая управляемость.

PHP, база данных и кэш

Если сайт на WordPress, Joomla, Drupal или другой CMS, новый сервер может иметь другую версию PHP, MariaDB/MySQL, расширений и лимитов. Сайт визуально может открываться, но часть функций или рекламных вставок может работать неправильно.

Проверьте:

• версия PHP совместима с CMS и плагинами;
• включены нужные PHP-расширения;
• лимиты memory_limit и max_execution_time достаточны;
• база импортирована полностью;
• кодировка базы не повреждена;
• таблицы не потеряны;
• кэш очищен после переноса;
• object cache не указывает на старый сервер;
• CDN cache очищен после переключения;
• cron-задачи работают;
• генерация sitemap работает;
• плагины рекламы работают.

Если сайт зарабатывает на контенте, не допускайте ситуации, когда страницы открываются, но часть шаблона, рекламных вставок или метаданных не загружается из-за PHP warning/fatal errors.

Проверьте скорость нового сервера

Скорость влияет не только на пользователей, но и на рекламные системы. Если сервер медленный, перегружен или периодически не отвечает, рекламный crawler может получать ошибки, а пользователи будут уходить до загрузки рекламы.

Проверьте до и после переезда:

• TTFB главной страницы;
• TTFB денежных URL;
• время генерации HTML;
• нагрузку CPU;
• использование RAM;
• скорость диска;
• ошибки PHP-FPM;
• медленные запросы к базе;
• ошибки 502/504;
• лимиты веб-сервера;
• количество одновременных подключений;
• поведение при пике трафика.

Если старый сервер был медленным, переезд должен улучшить ситуацию. Но если новый сервер настроен плохо, можно получить обратное: формально мощнее, фактически хуже.

Сделайте финальную синхронизацию

Если сайт статический, перенос простой. Если сайт динамический, нужна финальная синхронизация.

Особенно это важно, если на сайте есть:

• комментарии;
• формы;
• регистрация пользователей;
• личные кабинеты;
• заказы;
• платежи;
• обновление контента редакторами;
• автоматический импорт;
• генерация новых страниц;
• сбор статистики внутри CMS.

Перед переключением DNS нужно сделать короткое окно read-only или техническую паузу, затем повторно синхронизировать базу и файлы. Иначе часть новых данных останется на старом сервере.

Сделайте backup перед переключением

Перед миграцией нужен backup, который можно реально восстановить. Не “где-то есть копия”, а понятный архив файлов, базы данных и конфигов.

Сохраните:

• файлы сайта;
• базу данных;
• конфиги веб-сервера;
• PHP-конфиги;
• cron-задачи;
• robots.txt;
• ads.txt;
• sitemap-настройки;
• конфиги CDN/WAF;
• SSL-настройки;
• список DNS-записей;
• список рекламных блоков и мест размещения;
• текущие показатели дохода.

Backup на том же сервере — слабая защита. Если сервер удален или диск поврежден, такая копия не поможет.

План переключения DNS

В день миграции не должно быть импровизации. Нужен короткий план.

• Проверить, что новый сервер готов.
• Проверить сайт через hosts-файл.
• Сделать финальный backup.
• Сделать финальную синхронизацию файлов.
• Сделать финальную синхронизацию базы.
• Остановить изменения на старом сайте, если нужно.
• Проверить ads.txt на новом сервере.
• Проверить robots.txt на новом сервере.
• Проверить рекламные блоки на денежных страницах.
• Переключить A/AAAA/CNAME записи.
• Проверить сайт с нескольких сетей.
• Проверить рекламные блоки.
• Проверить логи нового сервера.
• Оставить старый сервер включенным.
• Следить за ошибками первые 24 часа.

Если сайт приносит деньги, переключение лучше делать в период минимального трафика, но не тогда, когда вся команда спит и никто не сможет быстро откатить ошибку.

Что проверять сразу после переключения

Первые 30-60 минут после смены DNS самые важные.

Проверьте:

• домен открывается с нового IP;
• главная страница работает;
• денежные URL работают;
• реклама отображается;
• ads.txt открывается и отдает 200;
• robots.txt открывается и не блокирует нужных роботов;
• sitemap.xml открывается;
• HTTPS сертификат корректный;
• редиректы не сломаны;
• мобильная версия работает;
• нет массовых 404;
• нет массовых 500/502/504;
• лог ошибок не растет;
• CPU/RAM в норме;
• база данных не упирается в лимиты;
• CDN видит новый origin.

Если что-то критично сломалось, не пытайтесь героически чинить на живом сайте часами. Откат на старый сервер часто дешевле, чем долгий простой.

Что смотреть первые 24 часа

После миграции проблема может проявиться не сразу. Рекламные системы, crawler-ы, кэш, DNS и пользователи приходят волнами.

Смотрите:

• доход по часам;
• количество рекламных показов;
• coverage/fill rate;
• ошибки AdSense crawler;
• предупреждения по ads.txt;
• статус сайта в РСЯ;
• ошибки в Google Search Console;
• ошибки в Яндекс Вебмастере;
• логи 4xx и 5xx;
• access log по рекламным и поисковым роботам;
• нагрузку сервера;
• ответы CDN/WAF;
• жалобы пользователей;
• просадку трафика по источникам.

Не делайте вывод по доходу за один час. Рекламный доход шумный. Но если одновременно упали показы, появились crawler errors и сервер отдает 5xx — это уже техническая проблема, а не сезонность.

Что смотреть первые 3-7 дней

Даже если первый день прошел нормально, наблюдение нужно продолжать.

• сравнить доход с обычными днями недели;
• сравнить рекламные показы;
• сравнить RPM;
• сравнить органический трафик;
• проверить Search Console;
• проверить Яндекс Вебмастер;
• проверить AdSense Policy Center и crawler errors;
• проверить интерфейс РСЯ;
• проверить ads.txt warnings;
• проверить серверные логи;
• проверить, что старый сервер почти не получает трафик;
• проверить, что CDN не держит старую версию.

Если через 3-7 дней все стабильно, можно вернуть DNS TTL к обычному значению и выключать старый сервер после проверки логов.

Как понять, что доход просел именно из-за миграции

Доход может меняться по многим причинам: сезонность, аукцион, рекламодатели, трафик, гео, поведение пользователей. Не каждое падение после миграции означает техническую ошибку.

Техническая причина вероятна, если одновременно появились такие признаки:

• снизилось количество рекламных показов;
• появились crawler errors;
• ads.txt стал недоступен;
• часть страниц отдает 404/500;
• TTFB резко вырос;
• CDN/WAF отдает 403 роботам;
• органический трафик просел из-за ошибок;
• Search Console показывает рост server error;
• Яндекс Вебмастер показывает недоступность страниц;
• рекламные блоки исчезли из шаблона;
• мобильная версия потеряла рекламу;
• robots.txt заблокировал нужных роботов.

Если трафик и показы стабильны, а RPM просел, причина может быть не в сервере. Но если показы и доступность упали вместе, сначала ищите техническую ошибку.

Как проверить доступ рекламных роботов

На новом сервере нужно смотреть access log. Там должно быть видно, что роботы заходят на страницы и получают нормальные ответы.

Проверяйте:

• Googlebot получает 200 на страницах;
• Mediapartners-Google не получает 403/500;
• YandexBot получает 200;
• YandexDirect не заблокирован robots.txt;
• ads.txt запрашивается и отдает 200;
• robots.txt отдает 200;
• нет challenge/captcha для роботов;
• нет rate limit на нужных crawler-ов;
• нет блокировки по стране дата-центра;
• нет блокировки по User-Agent.

Не доверяйте только браузеру. Браузер пользователя и crawler рекламной системы могут получать разные ответы из-за WAF, CDN, гео, cookies или User-Agent.

Роль геолокации сервера

Для доходного сайта локация сервера важна через скорость и доступность аудитории. Если основная аудитория в России, СНГ или Европе, сервер в слишком далекой локации может увеличить задержку. Если сайт работает через CDN, влияние origin-сервера меньше, но не исчезает полностью.

Выбирайте локацию по фактическим данным:

• где основная аудитория;
• где находятся рекламные и поисковые crawler-ы;
• какой TTFB из ключевых регионов;
• есть ли CDN;
• какой маршрут до пользователей;
• нет ли блокировок или проблем с IP-репутацией;
• как быстро сервер отвечает под нагрузкой.

Не выбирайте сервер только по цене. Для сайта, который приносит деньги каждый день, плохая сеть может стоить дороже экономии на тарифе.

IP-репутация нового сервера

IP-адрес нового сервера может иметь историю. Для обычного контентного сайта это не всегда критично, но стоит проверить базовые вещи:

• IP не находится в очевидных blacklist;
• с IP не идет чужой мусорный трафик;
• сервер не используется для почтовых рассылок без необходимости;
• на IP нет чужих сервисов;
• нет открытых proxy, DNS resolver или SMTP;
• сервер не отдает подозрительные заголовки;
• открыты только нужные порты.

Для рекламы важнее доступность сайта и соответствие правилам рекламной сети, но грязная серверная конфигурация может создавать сопутствующие проблемы.

Особенности WordPress-сайтов с AdSense или РСЯ

Большая часть контентных сайтов с рекламой работает на WordPress. У WordPress свои частые проблемы при миграции:

• плагин кэша хранит старые пути;
• объектный кэш указывает на старый Redis/Memcached;
• плагин рекламы не перенес настройки;
• тема потеряла вставки рекламных блоков;
• wp-cron не работает;
• права на uploads неправильные;
• карта сайта генерируется с ошибкой;
• старые URL дают 404;
• HTTPS mixed content ломает загрузку ресурсов;
• мобильный кэш отличается от десктопного;
• AMP-плагин работает иначе на новом сервере;
• security-плагин блокирует crawler-ов.

После миграции WordPress нужно очистить кэш, проверить permalink structure, рекламные вставки, sitemap, robots.txt, ads.txt и серверные логи.

Не забывайте про cron

Многие сайты используют cron для генерации sitemap, обновления контента, импорта, очистки кэша, публикации материалов, статистики и задач CMS. При переезде cron часто забывают.

Проверьте:

• cron-задачи перенесены;
• пути в cron актуальны;
• PHP CLI использует правильную версию;
• задачи не запускаются одновременно на старом и новом сервере;
• wp-cron или системный cron работает;
• нет ошибок в логах cron;
• задачи не перегружают сервер в пиковое время.

Если cron не работает, сайт может внешне открываться, но sitemap, кэш, импорт и публикации начнут ломаться позже.

Почта и формы

Сайт с рекламой часто имеет формы обратной связи, подписки, уведомления, комментарии и системные письма. При миграции почту легко сломать.

Проверьте:

• MX-записи не изменены случайно;
• почта не переехала без плана;
• SPF, DKIM, DMARC не сломаны;
• формы отправляют письма;
• SMTP-плагин работает;
• сервер не пытается отправлять почту с неподготовленного IP;
• уведомления CMS доходят;
• письма не падают в spam из-за смены сервера.

Если вы переносите только сайт, не трогайте почтовые DNS-записи без необходимости. Очень часто при миграции сайта случайно ломают почту.

Когда нужен откат

Откат — это не поражение. Это нормальный инструмент защиты дохода.

Откат нужен, если после переключения:

• сайт массово отдает 500/502/504;
• рекламные блоки пропали;
• ads.txt недоступен;
• robots.txt закрывает сайт;
• HTTPS сломан;
• денежные страницы отдают 404;
• новый сервер не держит нагрузку;
• база повреждена;
• CDN не может достучаться до origin;
• ошибка не чинится быстро.

Чтобы откат был возможен, старый сервер должен оставаться рабочим, база должна быть понятна, DNS TTL должен быть снижен, а команда должна знать, какие записи вернуть.

План отката до миграции

Перед переездом запишите:

• старый IP;
• новый IP;
• текущие DNS-записи;
• кто имеет доступ к DNS;
• кто имеет доступ к старому серверу;
• кто имеет доступ к новому серверу;
• где лежит backup;
• как вернуть сайт на старый сервер;
• что делать с базой, если появились новые данные;
• кто принимает решение об откате;
• сколько времени допустимо чинить без отката.

Если плана отката нет, вы будете принимать решения в панике, когда доход уже падает.

Что нельзя делать при переезде доходного сайта

• Нельзя переносить сайт без backup.
• Нельзя переключать DNS без проверки нового сервера.
• Нельзя выключать старый сервер сразу.
• Нельзя забывать ads.txt.
• Нельзя переносить staging robots.txt в production.
• Нельзя одновременно менять сервер, тему, рекламные блоки и структуру URL.
• Нельзя открывать сайт только в своем браузере и считать проверку законченной.
• Нельзя игнорировать 500/502/504 в логах.
• Нельзя блокировать рекламных роботов WAF-ом.
• Нельзя держать DNS TTL высоким до момента переключения.
• Нельзя переезжать в час пик трафика.
• Нельзя экономить на сервере, если сайт приносит стабильный доход.

Практический чек-лист до переезда

• Сняты показатели дохода за 3-7 дней.
• Список денежных URL подготовлен.
• Backup файлов сделан.
• Backup базы сделан.
• DNS-записи сохранены.
• TTL снижен заранее.
• Новый сервер настроен.
• Сайт проверен через hosts-файл.
• HTTPS работает.
• Редиректы совпадают со старым сервером.
• ads.txt открывается и отдает 200.
• robots.txt открывается и не блокирует нужных роботов.
• sitemap.xml работает.
• Рекламные блоки есть на денежных страницах.
• CDN/WAF не блокирует crawler-ов.
• PHP, база и кэш работают.
• Логи не показывают массовых ошибок.
• План отката записан.
• Старый сервер остается включенным после переключения.

Практический чек-лист после переезда

• Домен открывается с нового IP.
• Главная страница работает.
• Денежные URL работают.
• Рекламные блоки отображаются.
• ads.txt доступен.
• robots.txt доступен.
• sitemap.xml доступен.
• HTTPS без ошибок.
• Нет массовых 404.
• Нет массовых 500/502/504.
• CDN видит новый origin.
• WAF не режет рекламных роботов.
• AdSense не показывает новые crawler errors.
• РСЯ не теряет доступность страниц.
• Search Console не показывает резкий рост server errors.
• Яндекс Вебмастер не показывает массовую недоступность.
• Доход и показы отслеживаются по часам.
• Старый сервер получает все меньше трафика.
• Через 2-3 дня TTL можно вернуть к обычному значению.

Как HSTQ может помочь с таким переездом

Для сайта, который приносит деньги с РСЯ или AdSense, сервер нужно выбирать не только по цене. Важны стабильность, скорость ответа, запас ресурсов, понятная миграция, контроль DNS, проверка доступности, аккуратная настройка веб-сервера, SSL, кэша, логов и защита от ошибок при переключении.

HSTQ может помочь с переносом сайта на новый сервер, проверкой базовой серверной части, подготовкой окружения, настройкой SSL, nginx/Apache, PHP, базы данных, кэша и первичной диагностикой после миграции. Для доходного сайта особенно важно заранее проверить ads.txt, robots.txt, редиректы, рекламные блоки, HTTP-статусы и доступность сайта для рекламных роботов.

Если сайт уже приносит доход, не стоит переносить его “на глаз”. Перед обращением лучше подготовить: домен, текущий хостинг, CMS, размер сайта и базы, рекламные сети, средний трафик, список топовых страниц, текущие проблемы со скоростью и желаемое окно миграции.

Посмотреть услуги HSTQ можно здесь: https://hstq.net/.

Короткий практический финал

Переезд сайта с РСЯ или AdSense — это не просто перенос на новый сервер. Это защита ежедневного дохода. Сайт должен остаться доступным пользователям, поисковым роботам и рекламным crawler-ам. ads.txt должен открываться из корня домена. robots.txt не должен блокировать нужных роботов. Старый сервер должен работать после переключения DNS. Новый сервер должен выдерживать нагрузку и отдавать страницы быстро.

Самый безопасный подход: подготовить новый сервер, проверить сайт через hosts-файл, снизить DNS TTL заранее, перенести файлы и базу, проверить денежные URL, ads.txt, robots.txt, рекламу, HTTPS и редиректы, переключить DNS в спокойное окно, оставить старый сервер включенным и первые 3-7 дней смотреть доход, показы, crawler errors, логи и доступность.

Если сайт приносит деньги, миграция должна быть управляемой. Не надо экономить час подготовки, если ошибка может стоить нескольких дней рекламного дохода.