Ошибки WordPress и методы их устранения. Ограничение частоты сканирования Google

WordPress - самая популярная CMS в мире. Неудивительно, что пользователи этого движка сталкиваются с типичными проблемами и совершают распространенные ошибки. О каких ошибках идет речь и как их исправить?

Ошибка с мобильным меню

При попытке воспользоваться меню сайта пользователи могут столкнуться с проблемой (см. иллюстрацию).

Это происходит, если вы забыли указать мобильное меню в настройках WordPress. Чтобы исправить ошибку, в консоли выберите раздел «Внешний вид – Меню – Управление областями». Выберите нужное меню и сохраните изменения.

Проверьте доступность мобильного меню на сайте.

Ошибка структурированных данных (hatom, hcard)

Это очень распространенная ошибка, о которой владельцы ресурсов на WordPress обычно узнают благодаря уведомлениям в Search Console.

Откуда взялась ошибка? Большинство дизайн-шаблонов для WordPress по умолчанию поддерживают разметку с помощью микроформатов. Многие разработчики тем реализуют данные microformats.org с ошибками.

Мешают ли ошибки в структурированных данных пользователям? Нет, прямого влияния на пользовательский опыт они не оказывают. Микроразметка помогает поисковым системам корректно индексировать сайты.

В теории в будущем семантические данные могут стать фактором ранжирования. В этом случае ошибки в разметке будут негативно влиять на видимость ресурса в поиске. Также из-за ошибок поисковики не отображают на странице выдачи расширенный сниппет. Еще один аргумент в пользу работы над ошибками: соответствующие сообщения в Search Console просто раздражают.

Есть два способа исправить ошибку и один способ предупредить ее. Профилактика заключается в выборе дизайн-шаблона, в котором разметка microformats.org интегрирована корректно. Выберите тему с характеристиками SEO Friendly и , установите и проверьте с помощью инструмента тестирования микроразметки Google.

Обратите внимание, это не гарантирует отсутствия ошибок в структурированных данных, а только уменьшает их вероятность. Встречается такая проблема: тема проходит валидацию в сервисе Google, но после индексирования страниц в Search Console появляются сообщения об ошибках. В таком случае их нужно исправлять.

Первый способ - исправление ошибок с помощью плагина DT hAtom Error Removal . Обратите внимание, это коммерческий продукт, который автор в настоящее время распространяет бесплатно. Также обратите внимание на отсутствие этого плагина в официальном каталоге на WordPress.org. Это значит, что надстройка может не отвечать требованиям безопасности.

DT hAtom Error Removal автоматически удаляет микроформаты из файлов темы и добавляет корректный вариант разметки. Разработчик предупреждает, что надстройка работает не со всеми темами, поэтому стопроцентной гарантии исправления ошибок нет.

Установите и активируйте плагин. Чтобы исправить ошибки в разметке публикаций и страниц, отметьте флажком опции Add hAtom code to Posts и Add hAtom code to Pages. Сохраните изменения.

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

Созданная плагином разметка проходит валидацию.

Если на вашем ресурсе страницы архивов, меток и категорий открыты для индексации, а в Search Console есть сообщения об ошибках, отметьте флажком опцию Remove hentry class from Archive Pages. Она удаляет структурированные данные со страниц архивов. Если страницы архивов на вашем сайте закрыты от индексации, дополнительные настройки не требуются.

Если на вашем сайте используется статичная главная страница, отметьте флажком опцию Add hAtom code to Home Static Page. Если в качестве главной используется страница записей, отметьте опцию Remove Hentry class from Home page.

Существует еще один плагин, с помощью которого можно исправить ошибки размтеки. Hatom fix by Fivera.net платный. Обратите внимание, он также отсутствует в официальном каталоге WordPress.

Второй способ исправить ошибку можно назвать радикальным. С помощью плагина Hatom/hentry remover вы можете удалить микроформаты из любой темы. Разработчик утверждает, что использование надстройки не влияет на другие функции и внешний вид дизайн-шаблона.

Если вы используете другие типы разметки, удаление микроформатов - логичный шаг. Например, если вы размечаете публикации с помощью Article или BlogPosting Schema.org, поисковые системы получают семантические данные с помощью этого типа разметки. Микроформаты просто дублируют информацию, поэтому их можно удалить.

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

Неудобные для пользователей URL

Рекомендации по настройке ЧПУ есть практически в каждом руководстве по созданию сайтов на WordPress . Тем не менее многие владельцы сайтов используют недружественные к пользователям URL.

Почему дефолтные ссылки считаются неудобными для живых пользователей? Они неинформативные. Человеку ни о чем не говорит набор символов «/?p=112», поэтому ему сложно запомнить URL или оценить целесообразность перехода по ссылке. Сравните дефолтные ссылки с ЧПУ, которые выглядят так: https://site-wordpress/kotiki или https://site-wordpress/cats/britancy.

Чтобы настроить URL, установите плагин Cyr to Lat enhanced . Эта надстройка конвертирует в ссылках кириллические символы в латинские. После активации плагина перейдите в меню консоли «Настройки – Постоянные ссылки». Выберите подходящую по вашему мнению структуру URL и сохраните изменения.

Чтобы в URL отображалось название рубрики, на странице настроек постоянных ссылок установите флажок напротив опции «Произвольно». В пустом поле укажите значение /%category%/%postname%/.

Отсутствие ускоренных мобильных страниц

Эта стратегическая ошибка лишает ваш сайт доли мобильного трафика. Исправить ее можно в течение нескольких минут.

Основные тезисы, которые нужно знать об ускоренных мобильных страницах:

AMP - это сокращенная версия страниц сайта. На ускоренных страницах отображается только основной контент.
Google кэширует AMP с корректной разметкой, чтобы увеличить скорость загрузки страницы при просмотре с мобильных и использовании медленного подключения к интернету.
Крупнейший поисковик мира может показывать контент ускоренных страниц вашего сайта в карусели на странице поисковой выдачи.
AMP пока не дает преимуществ в ранжировании. Но если страницы сайта отображаются в карусели, вы получите больше трафика. Карусель находится в верхней части SERP.
Если вы используете мобильную версию или адаптивную верстку вместе с AMP, в выдаче Google отдаст предпочтение ускоренным мобильным страницам. То есть при корректной реализации AMP пользователи Google скорее попадут на ускоренные страницы сайта, а не на его мобильную или адаптивную версию.

Чтобы создать ускоренные мобильные страницы, воспользуйтесь плагином AMP от Automattic. После установки и активации на вашем сайте появятся AMP. Чтобы попасть на ускоренную страницу, добавьте к URL окончание /AMP/. Обратите внимание, плагин создает ускоренные страницы только для публикаций. Для категорий, тегов, статических страниц и главной AMP не создается.

Чтобы ускоренные страницы отображались в выдаче, они должны быть валидными .

После индексации AMP информация о них появится в Search Console в меню «Вид в поиске – Ускоренные мобильные страницы».

Обратите внимание, наличие на сайте ускоренных мобильных страниц не значит, что все владельцы смартфонов и планшетов при посещении вашего ресурса автоматически попадут на AM-версии страниц. Целесообразность направления пользователей из поиска на AMP определяет поисковая система.

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

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

Настройте отслеживание эффективности ускоренных страниц. Чтобы следить за посещениями AMP с помощью Google Analytics, установите и активируйте плагин AMP Analytics или AMP Toolbox . В настройках укажите идентификатор отслеживания GA.

Индексирование страниц пагинации

Практически на каждом сайте под управлением CMS WordPress есть страницы пагинации. Если не предпринимать никаких действий, в индексе поисковых систем могут появиться лишние страницы типа https://site-wordpress/page/2/ или https://site-wordpress/category/page/2/.

Google предлагает три способа решения проблемы:

Не делать ничего и позволить поисковику самостоятельно определять, нужно ли включать в индекс страницы пагинации.
Сделать страницу «Показать все» и указать ее в качестве канонической.
Использовать атрибуты rel="next" и rel="prev", чтобы указать поисковику на связь между страницами пагинации.

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

Что вызывает ошибку HTTP во время загрузки в WordPress?

Есть ряд вещей, которые могут привести к ошибке HTTP при попытке загрузить файлы с помощью медиа-загрузчика WordPress. WordPress не может понять причину, и поэтому он отображает общее сообщение об ошибке «HTTP error».

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

При этом мы рассмотрим, как устранить ошибку HTTP во время загрузки мультимедиа в WordPress.

1. Убедитесь, что HTTP-ошибка не временная

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

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

Если все эти шаги приводят к ошибке HTTP, это означает, что ошибка не вызвана временным сбоем и определенно требует вашего непосредственного внимания.

2. Увеличьте предел памяти WordPress

Наиболее распространенной причиной этой ошибки является нехватка памяти для использования WordPress. Чтобы исправить это, вам нужно увеличить объем памяти, который PHP может использовать на вашем сервере.

Вы можете сделать это, добавив следующий код в файл wp-config.php.

1 define("WP_MEMORY_LIMIT", "256M");

Этот код увеличивает предел памяти WordPress до 256 МБ, что достаточно для устранения проблем с ограничениями памяти.

3. Измените библиотеку редактора изображений, используемую WordPress

WordPress работает на PHP, который использует два модуля для обработки изображений. Эти модули называются GD Library и Imagick. WordPress может использовать любой из них, в зависимости от того, какой из них доступен.

Тем не менее, Imagick, как известно, часто сталкивается с проблемами памяти, вызывающими ошибку HTTP во время загрузки изображений. Чтобы исправить это, вы можете сделать библиотеку GD своим модулем изображений по умолчанию.

Вы можете сделать это, просто добавив этот код в файл functions.php вашей темы или плагин для конкретного сайта.

1 function wpb_image_editor_default_to_gd($editors) { 2 $gd_editor = "WP_Image_Editor_GD"; 3 $editors = array_diff($editors, array($gd_editor)); 4 array_unshift($editors, $gd_editor); 5 return $editors; 6 } 7 add_filter("wp_image_editors", "wpb_image_editor_default_to_gd");

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

4. Использование метода.htaccess

Этот метод позволяет вам контролировать Imagick, который использует серверные ресурсы. Многие хостинг-провайдеры ограничивают способность Imagick использовать несколько потоков для более быстрой обработки изображений. Однако это приводит к появлению ошибки HTTP при загрузке изображений.

Легким решением является добавление следующего кода в ваш файл.htaccess:

1 SetEnv MAGICK_THREAD_LIMIT 1

Этот код просто ограничивает Imagick одним потоком для обработки изображений.

Одной из самых популярных платформ на сегодняшний день является Worpress. Она имеет удобную административную консоль и с ней практически любому пользователю теперь под силу самостоятельно сделать свой собственный сайт. Но порой случаются сюрпризы, которые полностью парализуют работу сайта и ставят вас в тупик. И тогда перед глазами появляется ужасный белый экран смерти, неведомая PHP-ошибка, к которой привели неполадки на сервере, или плановые обновления плагинов, приведшие к краху сайта. Любую проблему можно решить, имея достаточно знаний и бесценный опыт. И в этот раз мы поговорим о внутренней ошибке сервера (Internal Server Error), а также о ее причинах и мерах устранения.

Ошибка 500 или внутренняя ошибка сервера (Internal Server Error)

Каждый, кто имеет собственный сайт на базе WordPress, тот хотя бы раз боролся с этой ошибкой и знает о ней не понаслышке. Основное коварство в том, что при ее возникновении изначально нет понимания конкретной причины, а соответственно и необходимых путей решения. Ряд этих самых причин довольно разнообразен, но вполне решаем.

Проблемы, из-за которых возникает Ошибка 500:

Конфликты в плагинах (обычно возникают после обновления)
Неполадки в теме сайта (возникают при обновлении родительской темы)
Ошибки в файле.htaccess
Превышен лимит PHP-память

Как устранить Ошибку 500.

Многих, особенно новичков, эта напасть может сильно напугать и поставить в настоящий тупик, но не стоит беспокоиться. Доступ к сайту через консоль нарушен, но на сервер можно попасть с помощью специального программного обеспечения. Поэтому паниковать не нужно.

Исправление файла.htaccess.

Основной и наиболее частой причиной этой проблемы является как раз некорректная работа файла htaccess. Чтобы исправить этот сбой вам необходимо авторизоваться в корневом каталоге WordPress, для этого подойдет специальный файловый менеджер (или ). Затем переименуйте его в.htaccess.back. После чего просто обновите окно и проверьте помогла ли данная мера. Если все хорошо, то дальше необходимо зайти в раздел «Параметры» -> «Постоянные ссылки» и нажать на «Сохранить изменения», чтобы новый файл.htacess перезапустился и перезаписал правила. Если не помогло, то переходим к плагинам.

Деактивация всех плагинов

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

Примечание: наличие Ошибки 500 блокирует доступ к административной панели сайта. В этом случае расширения удаляются или выключаются без доступа к панели, главное правильно следовать инструкции. После деактивации виновника сбоя — удалите его и загрузите альтернативу из магазина приложений. Вы можете оповестить создателя расширения об ошибке, что поможет улучшить имеющийся софт и оградить других пользователей от перспективы решать те же проблемы.

Если это решение не помогло, то нам придется менять тему.

Изменение темы

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

Восстановление директорий the «wp-admin» и «wp-includes».

Если сбой все еще присутствует, то можно произвести замену указанных папок свежими копиями из последней версии WordPress.

Увеличение лимита PHP-памяти.

Когда вышеперечисленное не помогло, то не надо отчаиваться. Придется всерьез поработать, чтобы все привести в порядок на вашем сервере. Ошибка 500 - решаема и это не конец вашего сайта. Если обстоятельства вынуждают вас применить крайние меры, то воспользовавшись Редактором кода необходимо написать текстовый файл, переименовав его в php.ini.
Внутри него необходимо прописать: memory=64MB
Загружаете сохраненный файл в папку «wp-admin». В случае устранения сбоя и расширения PHP-памяти необходимо выяснить у своего , что именно могло привести к перелимиту. У хостера имеется все записи из журнала операций, а причины могут быть какие угодно: от неправильно разработанных плагинов, до некорректной работы темы.

Материалы по теме:

Почему отображаются знаки вместо текста

Недавно ко мне обратился за помощью один знакомый. У него есть молодой сайт, на котором вместо текста стали отображаться различные иероглифы. Так как я...

Как добавить форму комментариев Vkontakte

Всем привет! Недавно, мне поступил заказ от клиента, он хотел, что бы я на его блоге разместил другую форму комментариев. От предложенного мною плагина...

Видео-хостинг для размещения видео на киносайтах

Всем привет! Заканчивая прошлую статью, про принадлежность Wordpress как CMS для кино сайтов, я упомянул, что в следующий статье напишу про видео хостинг, без которого...

Что только стоит увидеть на месте своего блога белый экран смерти или WSOD .

Для пользователей Windows системная ошибка называется BSOD и отличается синим цветом экрана. Наверно уже ознакомились и знайте как там в виндовс с этим борются.

Только в случае с блогом перезагрузкой компьютера проблему не исправить

Ах, ужас!

Обычно, WSOD не возникает на пустом месте и связан, чаще всего, с установкой какого-либо плагина, либо шаблона.

Вся неприятность данной ошибки … она блокирует админ-панель и сам сайт. Откатиться можно только при помощи файлового менеджера хостинга или по FTP-протоколу .

Например с отличной программой FileZilla

Почему возникает белый экран смерти блога?

установка плагина или шаблона, несовместимого с текущей версией движка
конфликт плагина с другим расширением или темой
обновление старого плагина, вызвавшее ошибку

В любом случае… отследить виновника несложно, если вы только что обновили некий плагин или шаблон. Как быть, если вы обновили одним махом 10-20 плагинов?

Очень просто…

переименовать каталог с плагинами (plugins1 к примеру) и создать новый с тем же названием, при этом движок перестанет видеть установленные плагины и можно будет включать их по одному, чтобы найти виновника.
переименовать текущий используемый шаблон , не забыв предварительно добавить стандартный шаблон (Twenty любой). После переименования WordPress переключится на доступную стандартную тему и можно будет зайти в админ-панель.

500 internal server error

Oшибки wordpress или одна ошибка довольно неприятная, но редкая. Чаще всего связана с неправильным файлом .htaccess в корневом каталоге сайта.

Лечится довольно просто – достаточно удалить его, затем зайти в админ-панель WordPress, перейти в раздел постоянных ссылок и сохранить еще раз желаемую структуру.

После сохранения WordPress создаст новый файл htaccess и с очень большой вероятностью ошибка пропадет.

Кроме этого, есть еще множество других причин возникновения ошибки 500.

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

Для этого добавьте в файл wp-config.php такую строку:

DEFINE (‘WP_DEBUG’, TRUE);

и затем уже смотреть журнал ошибок. В таком случае ошибка будет описана более подробно, что облегчит поиск и устранение.

Error establishing a database connection

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

неверный параметр соединения с базой данных . Какой-то из трех параметров подключения (адрес, логин, пароль) неверен, нужно перепроверить файл wp-config.php . Важно ! Убедитесь, что каждый из них заключен в одинарные кавычки.
не работает сервер баз данных MySQL . Если у вас VPS – необходимо перезагрузить сервер, если обычный хостинг – обратиться в техподдержку, пускай проверяют.

пользователь не имеет доступа к изменению таблиц БД . Для исправления необходимо добавить пользователю права(я ставлю обычно полный доступ к БД), делается это при помощи панели управления хости

An automated WordPress update has failed to complete

Ошибка довольно редкая, но иногда встречается. Чаще всего возникает, когда мощности хостинга не хватает для завершения автоматического обновления.

Качаем последнюю версию с ru.wordpress.org (ну или на вашем родном языке) и распаковываем
Отключаем все плагины на сайте, если это возможно
По FTP заходим в корневую папку сайта и удаляем директории wp-includes и wp-admin
Копируем эти папки из распакованного дистрибутива WP
Заменяем файлы в корневой папке на содержимое корня дистрибутива
Важно ! Не трогайте папку wp-content, надеюсь понятно, почему

Briefly unavailable for scheduled maintenance. Check back in a minute.

Простая до безобразия ошибка, решающаяся удалением файла .maintenance из корня сайта.

Возникает из-за неправильно завершившегося автоматического обновления. Если это так – вам поможет пункт выше. Но чаще всего просто автоматически не удаляется этот файл, только и всего.

FATAL ERROR: ALLOWED MEMORY SIZE OF -- BYTES EXHAUSTED

Эта ошибка WordPress возникает из-за недостатка памяти, выделенной для процесса PHP. Все, что вам нужно сделать, это увеличить количество памяти , если это возможно. Есть несколько способов сделать это:

Если вы можете редактировать файл php.ini, добавьте к нему строчку memory_limit = 64M (ну или найдите существующую и смените значение) и перезапустите сервер.
Отредактируйте.htaccess файл, расположенный в корневом каталоге, добавьте php_value memory_limit 64M.
Измените файл wp-config.php, добавьте DEFINE (‘WP_MEMORY_LIMIT, ’64M’);
Создаем php.ini файл внутри папки wp-admin c таким содержимым: memory_limit = 64M;

Какой-то из способов должен сработать Стоит заметить, что некоторые хостеры выделяют максимальный предел памяти на уровне 8-16М и не дают менять это значение. В таком случае я бы советовал замену хостинга.

Connection time out

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

Если же возможности нет – нужно снижать нагрузку:

увеличиваем лимит памяти (читаем выше)
по возможности – деактивируем не совсем нужные плагины
переход на стандартный шаблон, вроде Twenty Twelve

Maximum execution time of 30 seconds exceeded

Каждый файл PHP имеет максимальное время своего выполнения. Если он не “укладывается” в отведенные настройками рамки, возникает эта ошибка.

Чаще всего проблема возникает из-за неправильного функционирования дополнений (функция замыкается в цикле, к примеру).

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

Как вариант, можно попытаться увеличить максимальное время выполнения:

измените.htaccess в корневом каталоге WordPress, добавьте строку: php_value max_execution_time 60
измените, если есть возможность, файл php.ini, добавьте строку: max_execution_time = 60;

Ошибки, связанные со структурой БД

Я сталкивался только с двумя ошибками MySQL, возможно вариантов больше. Если у вас есть информация – поделитесь в комментариях, я дополню статью.

Ошибка 145 . Это значит, что структура БД повреждена и нуждается в восстановлении. При помощи phpMyAdmin или любого другого менеджера БД можно провести repair (восстановление стандартными средствами) Не забывайте про предварительный бэкап вашей базы 😉
Ошибка 28 . Не связаннная с WordPress ошибка, которая относится к самому MySQL. Решается при помощи техподдержки хостинга.

Друзья! Желаю вам не видеть на мониторе сообщение про !

Сергей Арсентьев

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

Кстати, эта статья появилась в результате небольшого SEO-эксперимента: я случайно собирал ключи для страницы с настройкой рекламы и нашел длинный незанятый SEO-запрос, а именно: "Ошибка установки соединения с базой данных WordPress".

В чём именно заключается мой SEO-эксперимент с этой статьей смотрите в конце текста

А сейчас - за дело! Итак, у вас выскочил белый экран и на нем ошибка установки соединения с базой данных.

Важно знать, что любой сайт на WordPress состоит из двух важнейших элементов: программных файлов и базы данных .

Программные файлы доступны на хостинг по FTP-соединению (). А база данных использует специальное место на хостинге, доступ в которое осуществляется через специальный сервис, обычно это PhpMyAdmin.

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

Для этого они получают к ней доступ, используя логин и пароль, заданный при первой настройке сайта на WordPress и хранящийся в файле wp-config.php в корневой (главной) папке сайта.

Выглядит это примерно вот так:

Поэтому если у вас возникает "Ошибка установки соединения с базой данных WordPress" или по английски: "Error establishing a database connection", то проблема заключается в том, что программный файл банально не может получить доступ к базе данных . По любой причине!

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

И следовательно, чтобы решить проблему ошибки установки соединения с базой данных WordPress, нужно проверить следующие моменты:

Убедиться, что база данных вообще существует. Для этого нужно зайти в панель управления хостингом (доступ выдает хостер при покупке его услуг - ), найти в меню панели ссылку на базы данных, обычно она так и называется "Базы данных", открыть и убедиться что база на хостинге существует.
Затем нужно зайти в саму базу и убедиться, что в ней есть информация (таблицы и записи), вдруг ее кто-то затер и на хостинге просто висит пустая база данных? Для этого нужно воспользоваться в панели хостинга ссылкой на сервис PhpMyAdmin и ввести логин и пароль от базы данных. Напомню - логин и пароль есть в файле wp-config. В самой базе должны быть какие-то таблицы, она должна весить определенный объем в Кб или Мб, то есть база должна быть непустой, занимать определенное место.
Если вы вводите логин и пароль и при этом доступ не открывается, значит скорее всего вы обнаружили корень проблемы возникающей ошибки - неправильное имя пользователя или (что скорее всего) неверный пароль. Возможно, вы его сменили для своей базы, а в файлах поменять забыли. Возвращайтесь на первый шаг, заходите в настройки базы данных, меняйте пароль у пользователя и после этого пропишите новый пароль в файле wp-config.php

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

Пароль от базы на хостинге = Паролю от базы в wp-config.php

Ну и в том, что база данных вообще есть, и вы ее случайно не стерли.

Кстати, если даже это произошло и вы обнаружили, что база данных удалена - не спешите паниковать, просто напишите хостеру просьбу о восстановлении бекапа база данных на заведомо рабочую дату и всё!

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

Вот и всё.
Ошибка несложная, и статья поэтому небольшая.
Если знаете свои способы решения данной ошибки установки соединения с базой сайтов на Вордпресс, пишите в комментариях. А если получилось решить задачу моими способами - ставьте лайки и звезды

SEO-эксперимент!

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

Его показатель KEI был небольшим, меньше 25 (что такое ), но при этом было много других сайтов с подобными запросами, только в сокращенной или искаженной форме:

Ошибка соединения с базой данных wordpress
Исправляем ошибку установки соединения с базой данных
Ошибка при установке соединения с базой данных и т.п.

Посмотрите - их нереально много!

Но с прямым вхождением ключа "Ошибка установки соединения с базой данных WordPress" в ТОП-10 Яндекса только 3 сайта.

И я решил выяснить: а если я оптимизирую статью под этот длинный запрос - он "победит" всех конкурентов с этим же запросом, но в другой форме? То есть насколько точная форма запроса помогает продвигаться в поиске.

Или можно особенно не заморачиваться над строгим соответствием в метатегах, заголовках, тексте статьи (читать ) и важнее все же другие SEO-факторы.

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

Кстати, и причем - совершенно бесплатно. Там есть секрет как это делать именно бесплатно, ведь сам по себе сервис платный.

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