Как перенести сайт на Timeweb и не получить технические проблемы в поиске? Начните не с переноса файлов, а с инвентаризации: какие URL должны остаться прежними, где расположены база данных и почта, как устроены резервные копии и что уже известно о доступности сайта для Googlebot и Яндекса. Ниже — мой рабочий сценарий смены хостинга на Timeweb для WordPress, MODX, Битрикс, OpenCart и обычных PHP-сайтов. Он нужен и владельцу бизнеса, и разработчику, и SEO-специалисту, который принимает результат.
Короткий ответ: если домен, протокол и пути страниц остаются прежними, это смена серверной инфраструктуры без смены URL. Для неё обычно не нужны массовые 301-редиректы и инструмент «Переезд сайта» в Яндекс Вебмастере. Нужны согласованные файлы и БД, правильные DNS, SSL, HTTP-ответы, robots/canonical, доступные формы и возможность отката. Если одновременно меняются адреса страниц или домен — это уже другой проект с картой URL и правилами перенаправлений.
Я занимаюсь техническим SEO с 2008 года и вижу, как переезд иногда «оптимизируют» до одного действия — меняют A-запись и радуются, что открылась главная. Потом выясняется: половина форм не отправляет письма, часть карточек отдаёт 404, вебхуки пишут заказы в старую базу, а поисковому боту показывают 503. В этой инструкции не обещаю сохранения позиций на 100%: задача — сделать ошибки обнаруживаемыми и управляемыми.
Что именно вы переносите: хостинг, домен или URL — это разные задачи
| Ситуация | Что меняется | Действия для SEO | Что не надо делать автоматически |
|---|---|---|---|
| Смена хостинга, адреса страниц прежние | IP / сервер / DNS A/AAAA/CNAME при необходимости | Проверить копию, коды, robots, canonical и логи до и после DNS | Не делать редирект всех URL на главную и не запускать «переезд домена» |
| Смена регистратора домена | Компания, продлевающая домен; DNS может остаться прежним | Контроль NS, DNSSEC и почтовых записей, если меняется DNS-провайдер | Не считать смену регистратора переносом файлов и БД |
| Перенос с HTTP на HTTPS или смена домена | Видимые адреса страниц | Карта старый→новый URL, 301, каноникал, внутренние ссылки, sitemap | Не смешивать с простой сменой IP |
| Смена CMS или структуры каталогов | Шаблоны, URL-логика, страницы и контент | Отдельный SEO acceptance: метаданные, рендер, пагинация, 301, robots | Не запускать редизайн и смену хостинга одним неконтролируемым релизом |
В руководстве Google по смене хостинга без изменения URL описана последовательность: подготовить инфраструктуру, изменить DNS, отслеживать старый и новый сервер и только потом отключить прежний. Раздел «Переезд сайта» Яндекса посвящён прежде всего изменению адресов (домен, www, HTTP/HTTPS); не переносите эту процедуру механически на смену IP.
Перенос сайта на Timeweb: шесть этапов с контрольными точками
Этап 1. Зафиксировать исходное состояние и требования
- Снимите список рабочих адресов: главная, услуги, карточки товаров, категории, страницы фильтров, пагинация, формы, robots.txt, sitemap.xml и значимые PDF. Сохраните HTTP-коды, title, canonical и цепочки перенаправлений.
- Снимите конфигурацию: версия PHP, MySQL/MariaDB, CMS, модули, cron, объём диска, лимиты CPU/процессов, параметры БД и API, SMTP, фоновые воркеры.
- Уточните доменную инфраструктуру: текущие NS/A/AAAA/CNAME, MX, SPF, DKIM, DMARC, TLS-сертификат, CDN, WAF, требования внешних сервисов к IP.
- Согласуйте окно переключения, кто отвечает за файлы/БД, письма, платежи и откат. Для магазина уточните, как обрабатываются заказы в момент финальной синхронизации.
Не все пункты нужны небольшому лендингу. Но если у сайта есть заявки и продажи, отсутствие ответственного за БД и почту — гораздо больший риск, чем выбор названия тарифа.
Этап 2. Создать согласованный бэкап и тестовую копию
- Сохраните файлы и дамп базы из одной согласованной точки времени. Проверьте права доступа и возможность восстановить их отдельно от старого аккаунта.
- Создайте окружение Timeweb и временный технический адрес либо безопасный предпросмотр с подменой DNS только у проверяющего. Timeweb описывает перенос через SSH и проверку на техническом домене.
- Проверьте, что резервные копии, дампы и конфигурации не доступны по публичному HTTP; ограничьте staging авторизацией или сетевым доступом. Для тестового домена не допускайте попадания дубликатов в индекс.
- Проведите пробное восстановление, а не только проверку наличия архива. Учтите права каталогов загрузок, кеша и файлов с секретами.
Официальная инструкция Timeweb по переносу через SSH предлагает использовать технический домен, чтобы проверить копию до переключения. Но такой адрес не нужно превращать во второй индексируемый сайт: если на тестовом стенде стоит noindex/запрет обхода, убедитесь, что он не унаследуется боевым сайтом после переключения.
Этап 3. Проверить сайт на новом сервере до изменения DNS
| Что проверять | Способ проверки | Признак готовности | Типичная ошибка |
|---|---|---|---|
| HTTP/HTTPS и редиректы | curl -I, браузер без авторизации, выборочный краулер | 200 на нужных URL, 301 там, где запланировано, корректный сертификат | 200 только на главной, а карточки 404/503 |
| SEO и индексирование | HTML-исходник, canonical, X-Robots-Tag, robots, sitemap | Те же значимые URL и разрешённый обход production | Остался noindex или robots staging |
| Данные и действия пользователя | Заявка, поиск, корзина, тест оплаты, загрузки | Записи фиксируются в нужной БД, письма доходят | Новые заказы пишутся в старый аккаунт |
| Сервер и защита | Проверка логов PHP/SQL, 5xx, WAF/anti-bot | Реальный пользователь и проверенный поисковый бот получают корректный ответ | WAF выдаёт 403/503 роботам |
| Почта, cron, API | MX, SMTP, SPF/DKIM, планировщик, вебхуки | Отправка и приём, очередь, интеграции работают | Сменили NS и потеряли почтовые записи |
| Скорость и восстановление | TTFB p50/p95, логи, восстановление БД | Понятные базовые значения и проверенная процедура rollback | Сравнивают только Lighthouse главной |
Если хочется проверить новый IP до переключения DNS, используйте отдельную тестовую машину и контролируемую резолюцию имени. При тесте HTTPS важны имя хоста в TLS и корректный сертификат; примитивная проверка IP по HTTP может ввести в заблуждение. Не публикуйте staging-адрес с закрытыми данными.
Этап 4. Переключить DNS и сохранить работу старого сервера
- Перед переключением согласуйте финальную синхронизацию изменяемых данных. Для магазина — окно записи заказов, для CRM — форм, для корпоративного сайта — заявок и сообщений.
- Обновите нужные DNS-записи у фактического DNS-провайдера; не путайте смену A/AAAA с передачей домена другому регистратору. Уточните TTL заранее, но не обещайте всем пользователям мгновенного обновления кешей DNS.
- Сохраните старый сервер и логи, пока на него ещё приходят запросы; при необходимости предусмотрите синхронизацию данных на этапе пересечения трафика.
- Сразу проверьте корректность HTTPS, 301, canonical, формы и бизнес-сценарии с разных сетей, не только с рабочего компьютера.
Этап 5. SEO-приёмка после переключения
Я смотрю не одну красивую главную, а небольшую репрезентативную выборку: коммерческая посадочная, категория, товар, фильтр, статья, пагинация, sitemap и robots. Именно она показывает системные нарушения генерации HTML, настройки rewrite и ограничения веб-сервера.
- Сравните до/после таблицу URL и HTTP-кодов; отдельным фильтром соберите 4xx/5xx, цепочки 301, отсутствующие canonical, случайный noindex и X-Robots-Tag.
- Сверьте robots.txt, XML-карту сайта, метаинформацию и реальные внутренние ссылки. При неизменных URL canonical обычно должны остаться прежними.
- Посмотрите access/error-логи обоих серверов и события WAF: не отдаёт ли антибот защиту на HTML-запросы проверенного робота.
- Проверьте Google Search Console и Яндекс Вебмастер на рост серверных ошибок, доступность важных URL и динамику обхода; учитывайте обычную задержку переобхода.
- Примите не только SEO, но и функциональность: формы, оплаты, почта, фоновые задания и резервное восстановление.
Этап 6. Отключить старый аккаунт только после фактического подтверждения
Google прямо рекомендует выводить старую инфраструктуру из работы после того, как она перестала обслуживать пользователей и поисковых роботов. Поэтому срок отключения задаётся не календарём «прошло 24 часа», а логами, DNS-наблюдением и состоянием данных. Сохраните аварийный бэкап и зафиксируйте, кто и куда откатывает проект при сбое.
WordPress, MODX, Битрикс и OpenCart: дополнительные проверки
| Сайт / CMS | Риск при переносе | Обязательная проверка | Подробное руководство |
|---|---|---|---|
| WordPress и WooCommerce | wp-config, сериализованные данные, кеш, фоновые события, checkout | Не выполнять слепой SQL find/replace по сериализованным полям; проверить корзину и письма | Хостинг WordPress |
| MODX Revolution | core/cache, xPDO, Extras, Friendly URLs, PHP 2.x/3.x | Права, сниппеты, TV, rewrite, контексты и конфигурация движка | Хостинг MODX |
| 1С-Битрикс | Обмен с 1С, PHP/SQL, агенты, кеш, лицензия | Системная проверка окружения, обмена и восстановления | Хостинг Битрикс |
| OpenCart/ocStore | config.php, OCMOD/Journal, cron, пути, сессии | Работа карточек/фильтров/корзины/оплаты и синхронизации заказов | Хостинг OpenCart |
| Next.js/Node.js | SSR/ISR, runtime, переменные окружения, серверный HTML | Исходный HTML для роботов, коды, canonical и API на новых маршрутах | Выбор VPS |
У WordPress, MODX и магазинов всегда есть второй слой задач — восстановить поведение приложения, а не просто файлы. Поэтому поддержку определённой CMS и подходящую версию PHP/БД я рассматриваю как необходимое, но недостаточное условие безопасного переноса.
Переезд сайта на Timeweb: стоимость, ограничения и вопросы поддержке
Считать стоимость нужно за полный период: новый тариф и продление, миграция, IP и SSL при необходимости, хранение резервов, параллельная оплата старого сервера, работа специалиста, мониторинг после переключения. Даже если перенос файлов технически бесплатный, время на тестирование магазина и поиск ошибки формы — реальная часть бюджета. Цену на конкретном тарифе лучше смотреть в день заказа, а не переписывать цифру из статьи прошлогодней давности.
| Вопрос Timeweb до оплаты | Зачем спрашивать | Какое доказательство получить |
|---|---|---|
| Может ли мой PHP/CMS/БД работать на выбранном тарифе? | Избежать несовместимости MODX Extras и модулей магазинов | Настройки, ограничения тарифа и тест |
| Есть ли технический домен/предпросмотр и можно ли тестировать копию? | Проверить до DNS и не показывать дубликат поиску | Письменный порядок, доступы и ограничения |
| Кто переносит файлы/БД и что именно входит в помощь? | Не перепутать содействие с полноценной SEO/бизнес-приёмкой | Чек-лист обязанностей исполнителя |
| Как устроены резервные копии и откат? | Проверить RPO/RTO и сохранность заказов | Регламент и тест восстановления |
| Сохраняются ли MX/SMTP/cron/вебхуки и логи? | Не потерять почту, заявки и фоновые процессы | Список настроек и тестовые события |
Что я бы сделал перед регистрацией. Сначала проверил бы технические требования и запросил у поддержки сценарий миграции именно своего сайта. Затем сравнил бы общие условия виртуального Timeweb с Timeweb Cloud и методикой VPS. Если текущий хостинг справляется с задачей и экономия не покрывает риск переноса, не менял бы его ради смены названия провайдера.
Если после этого Timeweb подходит по требованиям, можно проверить доступные варианты размещения на официальном сайте. Перед оплатой сверьте услуги, цену продления и условия переноса.
Что делать, если перенос уже прошёл неудачно: быстрый алгоритм
- Сайт не открывается: уточните DNS A/AAAA/NS, сертификат и HTTP-код; исключите ошибку конфигурации веб-сервера и не перепутайте её с глобальным DNS.
- Главная работает, разделы — 404: проверьте rewrite и Friendly URLs, пути CMS и права файлов.
- Формы не отправляют письма: SMTP, MX, SPF/DKIM, события сервера, очередь обработки и код приложения.
- Исчезли заказы: остановите хаотичное переключение, установите, в какой БД создавались данные в переходный период, согласуйте безопасное объединение и только потом продолжайте.
- Просели показы: начните с 5xx, robots/noindex/canonical/ответов Googlebot и Яндекса; поисковые позиции не всегда корректно сравнивать на следующий день после изменения инфраструктуры.
Частые вопросы о переносе сайта на новый хостинг
Нужно ли менять домен при переезде на Timeweb?
Нет. При обычной смене хостинга прежний домен и URL остаются. Могут измениться IP и DNS-записи. Регистратор домена тоже не обязан меняться.
Нужен ли 301 при смене IP?
Нет, если видимые URL не меняются. 301 нужен, когда реально изменён адрес и есть соответствие старой и новой страницы.
Как переносить сайт без потери SEO?
Не обещать невозможного, а зафиксировать исходные URL/коды, собрать и протестировать копию, корректно переключить DNS, сверить canonical/robots/SSL и мониторить логи. Это снижает технический риск, но не гарантирует позицию.
Нужно ли использовать «Переезд сайта» Яндекс Вебмастера?
Для одной лишь смены IP/хостинга обычно нет: этот механизм описан для изменения адресов. При смене домена, HTTP→HTTPS или www сценарий иной.
Можно ли протестировать сайт до переключения DNS?
Да. Используйте технический домен Timeweb, закрытый staging или резолюцию тестового имени на нужный IP. Проследите, чтобы копия не индексировалась, а запреты не перешли на production.
Как перенести WordPress без поломки ссылок?
Переносите файлы и базу согласованно, проверьте конфигурацию и постоянные ссылки, избегайте слепого SQL-replace для сериализованных данных, тестируйте формы и WooCommerce.
Что проверить при переносе MODX Revolution?
Совместимость PHP и Extras, конфигурацию xPDO, core/cache, Friendly URLs, права на файлы, контексты, сниппеты, robots и canonical.
Сколько занимает обновление DNS?
Зависит от TTL, резолверов и исходной инфраструктуры. Нельзя обещать единое время для всех пользователей. Держите старый хостинг до подтверждения переключения.
Перенос домена к другому регистратору — то же самое?
Нет. Передача прав обслуживания доменного имени и перенос файлов/БД на новый хостинг — независимые операции. Иногда они выполняются вместе, но не должны смешиваться без необходимости.
Когда отключать старый сервер?
Когда логи и проверки показывают, что он больше не обслуживает трафик, а новые данные не потеряются. Не по таймеру «через сутки».
Итоговый чек-лист и источники
Для себя я свожу проект к одной цепочке: инвентаризация URL и среды → согласованный бэкап → тестовая копия → проверка CMS, форм и SEO → DNS-переключение → проверка логов → отключение старого сервера. Это защищает бюджет и снижает риск простоя лучше, чем обещание «перенос без потери позиций за 15 минут».
Если задача пока только в подборе тарифа, переходите к разделу выбора хостинга. Для сравнения инфраструктуры — обзор Timeweb, обзор Timeweb Cloud и аренда VPS/VDS. Так выбор площадки и процесс миграции не смешиваются в одном гигантском обзоре.
Редакционная проверка: 18.10.2026. Основные источники: Google: смена хостинга без URL; Google: перенос с изменением URL; Яндекс Вебмастер: смена адресов; Timeweb: перенос через SSH. Тарифы и условия помощи проверяйте у провайдера. Материал носит справочно-технический характер. Некоторые ссылки на сервисы могут приносить автору вознаграждение; критерии оценки от этого не зависят.
Следующие страницы вас также могут заинтересовать:
- Робототехника
- Аутсорсинг: что это такое и как он может помочь вашему бизнесу?
- SEO-продвижение образовательного сайта: 7 лет — от старого HTML до AI Search
- Машинное зрение в робототехнике: что это, как работает и где применяется
- Паллетирование: что это такое, технологии, оборудование и роботизация
Обновлено: 19.10.2026