WordPress не подключается к базе данных: причины ошибки и восстановление сайта

Автор: Олеся Новикова | Опубликовано: 26.10.2026

Если сайт вместо главной страницы показывает сообщение о невозможности подключения к базе данных, проблема обычно лежит не в теме и не в плагинах, а в одном из трёх мест: неверные данные в wp-config.php, недоступный сервер MySQL/MariaDB или сломанные права пользователя базы. Реже причина в повреждённой базе данных или в ограничениях хостинга. Ниже — порядок проверки, который помогает не гадать, а быстро сузить источник сбоя.

Что именно означает эта ошибка

WordPress хранит почти весь контент и настройки в базе данных. Когда он не может открыть соединение с MySQL или MariaDB, ядро не получает доступ к таблицам и не может собрать страницу. Поэтому сайт становится недоступен целиком, включая админку.

По симптомам важно понять, с чем вы имеете дело:

если ошибка появилась сразу после переноса сайта, смены хостинга или восстановления из бэкапа, в первую очередь проверяйте параметры подключения;
если раньше всё работало, а потом сайт внезапно упал, вероятнее сбой сервера базы, переполненный диск, рестарт службы или проблемы у хостинга;
если WordPress сообщает о повреждении таблиц или предлагает режим восстановления базы, причина уже ближе к самой базе данных, а не к файлу конфигурации.

Сначала проверьте данные подключения в wp-config.php

Это самый частый и самый безопасный шаг. Файл wp-config.php лежит в корне сайта и содержит параметры, по которым WordPress подключается к базе. Проверьте четыре значения:

DB_NAME — имя базы данных;
DB_USER — пользователь базы;
DB_PASSWORD — пароль;
DB_HOST — адрес сервера базы.

Пример фрагмента файла:

define( 'DB_NAME', 'example_db' );
define( 'DB_USER', 'example_user' );
define( 'DB_PASSWORD', 'secret-password' );
define( 'DB_HOST', 'localhost' );

Что здесь проверять на практике:

после миграции часто меняются DB_NAME, DB_USER и DB_PASSWORD;
на некоторых хостингах DB_HOST — не localhost, а отдельный адрес или имя сервера, которое выдано в панели хостинга;
если у вас несколько сайтов на одном аккаунте, легко перепутать базу от другого проекта.

Если есть доступ к панели хостинга, сравните значения в wp-config.php с данными в разделе управления базами. Если пароль меняли недавно, обновите его и в конфиге, и в панели, если хостинг требует синхронизации доступа.

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

Убедитесь, что MySQL или MariaDB вообще работает

Даже при правильных данных WordPress не подключится, если служба базы данных остановлена или перегружена. На общем хостинге это обычно видно в панели: база может быть временно недоступна, сервер — в обслуживании, а в логах хостинга появляются ошибки соединения.

Если у вас VPS или выделенный сервер, проверьте состояние службы через SSH. Команда зависит от системы и имени сервиса, но чаще всего используют такие варианты:

systemctl status mysql
systemctl status mariadb

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

На хостинге без SSH ориентируйтесь на сообщения панели управления и поддержку. Если база недоступна из-за аварии на стороне провайдера, правка WordPress не поможет: нужно дождаться восстановления сервиса или переключиться на резервную копию, если она есть.

Проверьте права пользователя базы данных

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

В панели хостинга проверьте, что пользователь, указанный в DB_USER, действительно привязан к базе из DB_NAME и имеет все необходимые привилегии. Для WordPress обычно нужны права на чтение и запись таблиц, а не только доступ к просмотру.

Если у вас есть доступ к MySQL через консоль, можно проверить привилегии командой:

SHOW GRANTS FOR 'db_user'@'localhost';

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

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

Когда проблема в повреждённой базе данных

Если сайт не просто не подключается, а WordPress показывает сообщения о повреждении таблиц, ошибка может быть уже внутри базы. Такое бывает после аварийного выключения сервера, переполнения диска, неудачного обновления или сбоя на стороне MySQL/MariaDB.

Сначала попробуйте штатный механизм проверки и восстановления, который есть в WordPress. Для этого временно добавьте в wp-config.php строку:

define( 'WP_ALLOW_REPAIR', true );

После этого откройте в браузере адрес:

https://ваш-домен/wp-admin/maint/repair.php

На этой странице WordPress предложит проверку и восстановление базы. Это можно делать без входа в админку, но только на время диагностики. После завершения обязательно удалите строку WP_ALLOW_REPAIR из wp-config.php, иначе страницу восстановления сможет открыть любой посетитель.

Если штатное восстановление не помогло, остаются более серьёзные варианты: восстановление из резервной копии, ремонт таблиц средствами MySQL/MariaDB или работа через phpMyAdmin. Здесь уже важно понимать, какие именно таблицы повреждены и есть ли свежий бэкап. Если резервной копии нет, не спешите запускать агрессивные операции — можно ухудшить ситуацию.

Как отличить проблему WordPress от сбоя хостинга

Не каждая ошибка подключения означает, что сломался сам WordPress. Полезно смотреть на контекст:

если не открывается только один сайт, а другие сайты на том же аккаунте работают, вероятнее ошибка в настройках конкретного проекта;
если не работает несколько сайтов сразу, проблема может быть в общей базе, в сервере MySQL/MariaDB или в инфраструктуре хостинга;
если ошибка появилась после смены пароля базы или переноса, почти всегда виноваты параметры подключения или привязка пользователя;
если сайт падал и раньше, а потом начал выдавать разные ошибки, стоит проверить логи сервера и состояние диска.

Для диагностики полезны журналы ошибок веб-сервера и MySQL/MariaDB. Они не всегда доступны на общем хостинге, но если доступ есть, ищите сообщения о невозможности соединения, отказе в доступе, превышении лимитов или повреждении таблиц. Именно эти записи помогают понять, что чинить первым.

Безопасный порядок восстановления

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

Сделайте резервную копию файлов сайта и, если возможно, текущей базы.
Проверьте wp-config.php: имя базы, пользователя, пароль и хост.
Сверьте права пользователя базы в панели хостинга.
Убедитесь, что MySQL/MariaDB работает и не находится в аварийном состоянии.
Если есть признаки повреждения таблиц, запустите штатную проверку и восстановление базы.
Если ничего не помогло, восстановите сайт из последней рабочей резервной копии или обращайтесь в поддержку хостинга с конкретными данными: время сбоя, текст ошибки, имя базы и действия, которые уже проверили.

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

Что проверить после восстановления

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

После переноса или восстановления полезно ещё раз проверить wp-config.php, права пользователя базы и наличие актуального бэкапа. Если проблема возникла из-за переполненного диска или нестабильного сервера, имеет смысл сразу обсудить с хостингом лимиты и мониторинг, иначе сбой может повториться.

Если у вас есть только доступ к панели хостинга, начните с неё: в большинстве случаев именно там быстрее всего видно, верны ли данные базы и жива ли сама MySQL/MariaDB. Если доступ есть к SSH и логам, диагностика будет точнее, но и без них можно восстановить сайт, если идти по этой последовательности.