После переезда WordPress на новый хостинг сайт может встретить вас не приветствием, а сухой надписью об ошибке подключения к базе данных. Чаще всего это не катастрофа, а следствие пары неточных настроек, которые легко пропустить в спешке. Проблема неприятная, но обычно она быстро сдается, если проверять все по порядку и не гадать наугад.
Почему ошибка появляется именно после переезда
Перенос сайта почти всегда затрагивает два чувствительных места: саму базу данных и файл конфигурации WordPress. Если хотя бы одно из звеньев не совпадает с новыми данными хостинга, сайт не может обратиться к таблицам и вместо страницы показывает ошибку подключения.
На старом сервере могли работать одни параметры, а на новом оказались другие. Меняются имя базы, пользователь, пароль, адрес сервера MySQL, иногда даже префикс таблиц. Для WordPress это уже повод остановиться, потому что он не умеет «догадываться» и пытается подключиться только по тем значениям, которые записаны в wp-config.php.
Еще одна частая история связана с тем, что база была перенесена не полностью или импорт прошел с ошибкой. Внешне все выглядит аккуратно: файлы лежат на месте, домен прикручен, но внутри базы не хватает таблиц или в ней повреждены записи. В такой ситуации сайт тоже не поднимется.
Ниже полезно держать простую мысль: если ошибка появилась сразу после переезда, почти всегда проблема в связке «настройки доступа плюс сама база», а не в теме, плагинах или кэше.
«Сайт ломается не там, где пользователь это видит, а там, где ему отказали в праве на доступ к данным». — эта фраза хорошо описывает поведение WordPress после неправильного переноса.
С чего начать проверку в wp-config.php
Файл wp-config.php хранит все данные, по которым WordPress подключается к базе. Это первое место, куда стоит заглянуть, если после переноса появился сбой. Обычно именно здесь находится причина, даже если она выглядит как одна пропущенная буква в имени базы или неверный пароль.
Откройте файл через файловый менеджер хостинга или по FTP и сравните значения с теми, что выдал новый провайдер. Важно проверить DB_NAME, DB_USER, DB_PASSWORD и DB_HOST. Если хоть одна строка не совпадает, сайт не установит соединение.
Отдельного внимания требует DB_HOST. На одном хостинге это может быть localhost, на другом — конкретный адрес сервера или имя вроде mysql123.hosting.example. Многие по привычке оставляют старое значение и именно на этом теряют время. Впрочем, это легко исправить, если данные из панели хостинга под рукой.
Если вы переносили сайт вручную, проверьте еще и кодировку файла. Иногда конфиг сохраняется с лишними символами или в неподходящем формате, и это тоже может мешать работе. Такие случаи редки, но исключать их не стоит.
Как понять, что база импортировалась без сбоев
Даже правильный wp-config.php не спасет, если база данных не загрузилась полностью. После переноса стоит открыть phpMyAdmin на новом хостинге и посмотреть, есть ли в базе таблицы WordPress. Их должно быть заметно больше одной-двух, обычно это десятки таблиц с префиксом wp_ или другим, если он был изменен.
Если таблиц нет, импорт не удался. Иногда файл .sql слишком большой, и процесс обрывается по тайм-ауту. Бывает и так, что архив распаковали, но сам импорт в базу не выполнили. Со стороны это выглядит одинаково: сайт не открывается, а причина лежит в незавершенном переносе.
Если таблицы есть, но сайт все равно не работает, посмотрите на их состояние. Поврежденные таблицы могут дать тот же эффект, что и пустая база. В phpMyAdmin обычно видно, есть ли ошибки обслуживания, а для WordPress полезна встроенная проверка, если добавить в конфиг режим ремонта.
| Что проверить | Где смотреть | Что должно быть в норме |
|---|---|---|
| Имя базы | wp-config.php | Совпадает с данными нового хостинга |
| Пользователь базы | wp-config.php и панель хостинга | Создан на новом сервере и привязан к базе |
| Пароль | wp-config.php | Введен без ошибок и совпадает с тем, что задан в панели |
| Таблицы | phpMyAdmin | Есть полный набор таблиц WordPress |
«Половина проблем с переносом сайта решается не магией, а сравнением трех строк в конфиге и одной базы в phpMyAdmin». Это мнение часто повторяют системные администраторы, и в нем мало романтики, зато много правды.
Когда виноват не пароль, а права доступа
Иногда данные в wp-config.php выглядят безупречно, но соединения все равно нет. В таком случае стоит проверить, привязан ли пользователь базы к самой базе данных и есть ли у него нужные права. На новом хостинге это отдельный шаг, который легко упустить.
Некоторые панели создают базу и пользователя по отдельности, а связать их между собой нужно вручную. Если этого не сделать, WordPress будет пытаться войти в базу с правильным логином и паролем, но сервер ему откажет. Внешне это почти не отличается от обычной ошибки подключения, хотя причина совсем другая.
Полезно также убедиться, что пользователь имеет права на чтение, запись, изменение и удаление таблиц. Для WordPress это стандартный набор. Если доступны только часть действий, сайт может открываться нестабильно или зависать на этапе загрузки.
Из личной практики могу сказать: такие мелочи особенно любят прятаться после быстрого ручного переноса. Архив распакован, база импортирована, домен работает, а сайт молчит только из-за невыданных прав. Проверка занимает минуту, а поиски иногда растягиваются на час.
Если проблема в таблицах, а не в подключении
Бывает и так, что доступ к базе есть, но WordPress не может прочитать данные из-за повреждения таблиц. Такое случается после неудачного импорта, падения сервера или обрыва соединения во время копирования. В этом случае ошибка подключения может маскировать более глубокую проблему.
Для начала можно попробовать стандартное восстановление через phpMyAdmin. Если повреждение незначительное, таблицы удается починить без серьезных потерь. Но если ошибок много, разумнее восстановить базу из резервной копии, а не чинить все вручную.
WordPress умеет запускать режим ремонта базы. Для этого в wp-config.php добавляют строку с разрешением на обслуживание, после чего открывают специальный адрес сайта. Этот способ полезен, когда панель хостинга недоступна или phpMyAdmin показывает проблемы с несколькими таблицами сразу.
Но здесь важно не затягивать. Режим ремонта нужен только на время проверки. После исправления его убирают из конфигурации, чтобы никто посторонний не мог воспользоваться этой возможностью.
Что стоит сделать в первую очередь
Если сайт не открывается сразу после переноса, лучше идти коротким маршрутом. Он экономит время и помогает не запутаться в догадках. Сначала проверяют доступы, затем саму базу, потом уже кэш и редкие причины.
- Сравнить данные в wp-config.php с параметрами нового хостинга.
- Проверить, создана ли база и импортированы ли таблицы.
- Убедиться, что пользователь привязан к базе и имеет права.
- Посмотреть, нет ли ошибок в phpMyAdmin.
- Только после этого переходить к дополнительным проверкам.
Такой порядок почти всегда дает ответ быстрее, чем беспорядочные попытки менять все подряд. WordPress не любит хаотичных правок, зато охотно запускается, когда получает точные данные.
Что еще может мешать после переезда
Иногда источник проблемы лежит чуть в стороне от базы, хотя выглядит как тот же самый сбой. Например, на новом хостинге может быть другая версия PHP, и старый набор плагинов начинает вести себя нестабильно. Обычно это не вызывает именно ошибку подключения, но в сложных случаях диагностика становится запутанной.
Стоит также проверить, не подключен ли внешний кэш или не остались ли старые настройки CDN. Если сайт переносили вместе с кеширующими плагинами, они могли сохранить старые параметры доступа или ссылаться на прежний сервер. После очистки кэша ситуация часто меняется сразу.
Еще одна деталь, о которой забывают: домен мог указывать на новый хостинг не полностью, а DNS еще не обновился. Тогда часть запросов уходит на старый сервер, часть на новый, и картина получается странной. В такой момент легко принять сетевую задержку за проблему с базой.
Однако если ошибка возникла строго после копирования сайта и не менялась несколько часов, основной подозреваемый все равно один: база, ее доступы или импорт.
Как избежать повторения этой ошибки при следующем переносе
Самый надежный способ сэкономить себе нервы — делать перенос по чек-листу. Он не должен быть длинным, но в нем обязаны быть все важные шаги: резервная копия файлов и базы, проверка доступа к новой базе, импорт, настройка wp-config.php, тест входа в админку и быстрая проверка фронтенда.
Неплохо заранее сохранить старые данные доступа, даже если кажется, что они больше не пригодятся. При переносе WordPress именно память подводит чаще всего: имя базы вспоминается неточно, пароль теряется, а время уходит на восстановление по обрывкам. Записанные параметры решают эту проблему без лишней суеты.
Полезно после переноса открыть phpMyAdmin и убедиться, что таблицы на месте, а затем проверить главную страницу и админку. На это уходит немного времени, зато сразу видно, есть ли связь с базой или где-то нужно поправить настройки. Такой простой осмотр избавляет от долгих поисков уже после запуска сайта.
И если ошибка все же появилась, не стоит воспринимать ее как что-то загадочное. Обычно это всего лишь сигнал, что WordPress не получил правильный адрес к своим данным. Как только связь с базой восстановлена, сайт возвращается к обычной работе довольно быстро.
