Деактивация темы WordPress. Использование Favicon по умолчанию

Видите ошибку 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 одним потоком для обработки изображений.

Все делают ошибки. Оскар Уайльд прекрасно выразился на этот счет: «Опыт – это имя, который каждый дает своим ошибкам». Опыт – это прекрасный учитель, каждый действительно учится на своих ошибках. Однако все же не мешало бы следовать известной пословице и учиться на чужих ошибках. В этой статье я расскажу о 25 самых распространенных ошибках вордпресс, которые совершает практически каждый новичок. Надеюсь, это поможет вам самим избежать их.

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

2. Покупка того, что не нужно

Если вы хотите обзавестись WordPress сайтом, то что действительно вам нужно, так это и веб-хостинг. Однако многие регистраторы доменов предлагают еще целый ряд, по сути, не нужных услуг, что сбивает с толку владельцев малого бизнеса и новичков в сфере веб-разработок. В качестве примера таких услуг: приватная регистрация, брендинговые письма, протокол SSL, 5-ти летняя регистрация и т.д.

Почему, например, не нужна приватная регистрация? У WPbeginners был клиент с этой услугой, и когда понадобилось просто перенести домен, потребовалось отправить: копию водительского удостоверения, свидетельство о регистрации и кучу другой конфиденциальной информации. В общем, одна головная боль. Брендинговые письма можно легко самому создать с помощью приложения Google Web Apps. В большинстве случаев не нужен и SSL-протокол.

Также я не вижу никакого смысла платить вперед за 5 лет регистрации домена. Мало ли что может произойти, может, вы вообще забросите этот сайт? Что тогда? Деньги на ветер? Если дело в экономии, то вполне возможно в будущем появятся скидки, и вы сохраните больше денег без всякой 5-ти летней регистрации.

3. Несоздание резервной копии

Если вы не создали резервную копию сайта, то вы поймете, что совершили огромную WordPress ошибку, когда сайт «полетит» и вам придется его восстанавливать с нуля. Я всем настоятельно рекомендую делать бэкап сайта в автоматическом режиме. Благо для этого существуют специальные плагины. Навскидку я могу вспомнить о трех из них: , VaultPress (платныйe), и BackWPup (бесплатный).

Примеры из жизни:

“Упала база данных у WP сайта, у меня не было резервной копии. При импорте новой базы данных у меня естественно появилось сообщение об ошибке”.

“Сделал SQL-запрос без какого-либо бэкапа. Сами понимаете, что отменить это нельзя».

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

Так что, если не хотите лишних проблем и нервотрепки, то не повторяйте эту распространенную ошибку в WordPress – начните уже сейчас делать бэкап.

4. Игнорирование WordPress обновлений

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

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

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

5. Использование Favicon по умолчанию

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

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

6. Обновление functions.php без доступа к FTP

Мы все хотя бы раз сталкивались с блокировкой сайта из-за неправильной передачи с админки WP кода в файл темы functions.php. Дела обстоят еще хуже, когда нет FTP-доступа или мы не знаем, как им пользоваться. Чтобы предотвратить эту WordPress ошибку я написал руководство для новичков: как вставлять сниппеты (на стадии написания).

Я также посоветовал бы не часто использовать встроенные WP-редакторы. Вот инструкция о том, как в WordPress отключить тему & редакторы плагина (на стадии написания).

7. Слишком много категорий

В вордпрессе очень легко добавлять категории. Не увлекайтесь! Не надо создавать новую категорию чуть ли не для каждой новой записи. Не надо нагромождать структуру сайта, ведь не только пользователи, но и вы сами потом запутаетесь в ней. Чтобы не совершить эту ошибку вордпресс, я советую ознакомиться со статьей Категории против Тегов – лучшие примеры.

8. Не настройка постоянных ссылок

Достаточно долгое время мы по умолчанию использовали следующую структуру урл: / ? p = 23 . Но это плохо не только для SEO, но и для пользователей. При установке WordPress убедитесь, что вы обновили структуру своих постоянных ссылок через маршрут Settings » Permalinks .

9. Игнорирование SEO настроек

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

Я также знаю случай, когда после редизайна люди получали свой сайт полностью со слетевшей индексацией.

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

10. Изменение урла сайта и потеря всего трафика

Как много среди нас тех, кто, набравшись опыта в ведении сайта или блога, возненавидел свой первый домен и захотел его поменять? Да, такое частенько случается. Самое ужасное, что может случиться при неправильном переносе домена, это значительное падение трафика, а, следовательно, обвал доходов. Не совершайте эту ошибку вордпресс. Именно поэтому я написал руководство, как правильно перенести WordPress сайт на новый домен.

11. Отсутствие плагина кэширования

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

12. Выбор WordPress темы с плохого источника

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

13. Отсутствие контактной формы

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

14. Отсутствие аналитики

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

Google Analytics предоставляет кучу полезной информации о вашем сайте, дает знать и где и что не мешало бы подправить. Я бы также настоятельно порекомендовал установить Google Webmaster Tools.

Предлагаю вашему вниманию две полезные статьи:

15. Написание статей в Microsoft Word

Возможно, для вас это станет открытием, но создавать записи в Microsoft Word, а потом добавлять их на сайт – это WordPress ошибка. А что если у вас отключится комп? (какой-то сбой, задели шнур, отключили свет и т.п.). Вся работа насмарку? Придется все заново делать? Кроме того, скопировав текст с Microsoft Word и вставив его на сайт, вы добавите кучу каких-то непонятных и не нужных символов, форматов.

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

Лично мое мнение: я всегда пишу статьи в Microsoft Word, а потом добавляю на сайт. По поводу того, что отключат свет, электричество это все бред на самом деле. Вы можете просто через определенное количество абзацев сохранять свои изменения и будет вам счастье, даже если вас обесточат, а чтобы данные не потерялись, то храните их в облачных сервисах, например в Dropbox.

16. Тег «еще один блог»

По умолчанию каждый раз при установке WordPress к нему прибавляется тег «Еще один блог». Частенько новички не знают об этом, и пробел в знании восполняется только тогда, когда сайт начинает индексироваться с этим «Еще один блог…». Изменить тег можно, пройдя по маршруту Settings » General .

17. Не удаление тестовой страницы

Раньше по умолчанию у WordPress шла страница «О себе», сейчас это «Образец страницы». Быстрый поиск в google показал, что существует, по меньшей мере, 1,1 миллион сайтов с этой страничкой. Большинство пользователей просто не знают об этом, либо не хотят удалять ее.

Если она есть и на вашем сайте, то немедленно удалите ее.

18. Несвоевременная проверка комментариев

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

Если вам не нужны комментарии на сайте, то просто отключите эту функцию с помощью плагина

19. Ошибка установления соединения с базой данных

Это даже не ошибка, а больше сбой, который может возникнуть в случае неправильных действий. Вы используете один и тот же пароль для базы данных и для cPanel? Если вы поменяли этот пароль, то у вас могут возникнуть проблемы с подключением к базе данных. Это может также случиться, когда вы меняете пароль для основного пользователя на хостинге, который является также и пользователем базы данных вашего сайта. Именно поэтому вы всегда должны создавать конкретного пользователя для базы данных своего сайта. Однако такой сбой может произойти и по другой причине.

20. Белый экран смерти

Если вам больше 18 лет, то вы наверняка не понаслышке знаете о синем экране смерти на ПК. У WordPress есть подобное, вот только называется оно белым экраном смерти. Это может произойти, если вы установите плохой плагин или тему, которые исчерпают лимит памяти сайта. В большинстве случаев вы можете легко исправить эту ошибку, увеличив лимит памяти. О других способах можно узнать, как исправить белый экран смерти в WordPress.

21. Чрезмерно длинный архив

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

22. Неиспользование функции «сохранить для веб-страниц»

В самом начале ведения сайта многие пользователи не задумываются о том, насколько много весят, загружаемые изображения. И только со временем приходит осознание, что вместительность у сайта не резиновая и все изображения надо сжимать. Изображение может намного меньше весить, если мы просто применим к нему функцию «сохранить для веб-страниц» и при этом зачастую оно нисколько не потеряет в качестве. Данная функция есть у Adobe Photoshop, Microsoft office, GIMP, JPEG Mini.

Частенько пользователи не задумываются о безопасности сайта, пока их не взломают. По этой же причине они начинают делать резервные копии. Я настоятельно рекомендую задуматься о безопасности сайта и сделать следующее:

  • Создать резервную копию
  • Установить лимит на количество раз введение логина
  • Использовать двухфакторную аутентификацию при помощи Google Authenticator
  • Использовать плагин безопасности Sucuri.
日本語 ()

Contents

Description

WP_Error is a class that makes error handling within plugins and WordPress itself much easier.

Instances of WP_Error store error codes and messages representing one or more errors, and whether or not a variable is an instance of WP_Error can be determined using the function.

Error Codes

Error codes are slugs that are used to identify each error. They are mostly useful when a piece of code can produce several different errors, and you want to handle each of those errors differently.

The error codes used in WordPress are not integers, but strings, with any spaces between words replaced with underscores (example: an_error_code). The error codes used in WordPress are usually based on the error message associated with that code.

Methods and Properties

Properties

$errors Array containing the list of errors. $error_data Array containing the list of data for error codes.

Note: Since 4.0, these properties are private, see . Then were then made public again in .

Methods

__construct($code = "", $message = "", $data = "") Sets up the error message. All parameters are optional, and if the $code parameter is empty, the other parameters will be ignored. When you pass a value for the $code parameter, the $message will be added for that code, even if you did not pass a value for $message (but $data will be used only when you pass a value for $data). It is possible to add multiple messages to the same code by using other methods in the class. get_error_codes() Retrieve all error codes. Access public, returns array List of error codes, if available. get_error_code() Retrieve first error code available. Access public, returns string, int or Empty if there is no error codes get_error_messages($code) Retrieve all error messages or error messages matching code. Access public, returns an array of error strings on success, or empty array on failure (if using code parameter) get_error_message($code) Get single error message. This will get the first message available for the code. If no code is given then the first code available will be used. Returns an error string. get_error_data($code) Retrieve error data for error code. Returns mixed or null, if no errors. add($code, $message, $data) Append more error messages to list of error messages. No return. add_data($data, $code) Add data for error code. The error code can only contain one error data. No return. remove($code) Remove any messages and data associated with an error code. No return.

Example

function doer_of_stuff() { return new WP_Error("broke", __("I"ve fallen and can"t get up", "my_textdomain")); } $return = doer_of_stuff(); if(is_wp_error($return)) { echo $return->get_error_message(); }

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", чтобы указать поисковику на связь между страницами пагинации.

Крушите свой рабочий стол в приступе отчаяния? Досадная ошибка привела к тому, что вы разлюбили WordPress ?

WordPress – это замечательная платформа для блогов и система управления контентом, но нет программного обеспечения без ошибок. В этой статье рассматриваются искусные решения трех самых распространенных ошибок WordPress : «Белый экран смерти », «Внутренняя ошибка сервера » и «Ошибка установки соединения с базой данных ».

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

1) Белый экран смерти

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

  • Нехватка памяти;
  • Плагин;
  • Тема.

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

Нехватка памяти

Часто проблемой, стоящей за этой ошибкой, является достижение лимита доступной памяти. Чтобы увеличить объем доступной памяти, найдите файл wp-config.php : перейдите к корневому каталогу вашего сайта с помощью FTP -клиента или файлового менеджера на панели управления хостингом. Внутри основного php тега нужно будет добавить строку кода, которая увеличит предельный лимит памяти до 64 МБ:

define("WP_MEMORY_LIMIT", "64M");

Можно задать и больше, чем 64 МБ, но это уже зависит от вашего сервера, поэтому 64 МБ, как правило, является безопасным вариантом. Возможно, увеличение памяти не помогло, или вы уже задали лимит выше 64 МБ? Тогда проблема может заключаться в плагинах или вашей теме.

Плагины

Если у вас есть доступ к панели администрирования, проблемы с плагинами легко решаются. Просто перейдите в раздел «Плагины » (Plugins ) и отключите последний установленный плагин. Если это не помогло, можно отключить все плагины вашего сайта, для этого выделите их, поставив галочку в самом верху, и выберете команду «Отключить » (Deactivate ).

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

Зайдите в каталог wp-content/plugins , в котором содержатся все установленные плагины. Просто переименуйте папку plugins , например, добавив слово в конец таким образом, что plugins станет plugins-test .

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

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

Темы

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

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

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

Включение отладки PHP-кода

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

Сначала, откройте файл wp-config.php . И найдите в нем следующую строку:

define("WP_DEBUG", false);

Поместите ‘//’ в начале строки, так чтобы получилось:

//define("WP_DEBUG", false);

Теперь эта строка закомментирована. Следующий шаг: вставьте приведенный ниже код сразу после данной строки:

define("WP_DEBUG", true); define("WP_DEBUG_LOG", true); define("WP_DEBUG_DISPLAY", false); @ini_set("display_errors",0);

Вот тут вам потребуются небольшие знания программирования. Действия, которые мы предприняли, позволят направить ошибки в файл под названием error.log (который находится в папке wp-content ). Если вы не можете его найти, возможно, у вас нет прав для его создания. Просто создайте новый файл error.log и задайте для него права доступа 666 .

Откройте файл error.log в текстовом редакторе и проверьте на ошибки PHP . Если это то, что вы не понимаете или в чем не уверены, то целесообразнее обратиться к кому-нибудь за помощью.

2) Внутренняя ошибка сервера

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

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

Плагины или тема

Обратитесь к секциям «Плагины » и «Темы » из предыдущего раздела. Метод решения проблемы полностью аналогичен.

Нехватка памяти

И снова, это решается так же, как описано в предыдущем разделе.

Некорректный.htaccess

Дело не в ваших плагинах и не в теме? Тогда пришло время проверить, не поврежден ли файл .htaccess . Сначала переименуйте данный файл - снова просто добавьте в конец «temp » или что-нибудь подобное. Не видите этот файл?

Тогда убедитесь, что вы включили опцию «отображать скрытые файлы ». Как именно это сделать, зависит от вашего FTP -клиента, но это довольно просто. Например, в Filezilla , просто выберете сверху «Сервер » (Server ) и затем - «Показывать скрытые файлы » (Show hidden files ).

Теперь следующий шаг - сначала вернитесь назад в панель администрирования WordPress . Пройдите в «Настройки - Постоянные ссылки » (Settings – Permalinks ) и затем сбросьте ваши постоянные ссылки. Сейчас вы сгенерировали новую версию рабочего файла, поэтому вы можете проверить, была ли решена проблема.

Включение PHP отладки

Это тоже было описано в разделе выше, поэтому снова пролистайте вверх.

3) Ошибка при установке соединения с базой данных

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

Если вы видите такое же сообщение об ошибке на серверной стороне (wp-admin ) «Ошибка при установке соединения с базой данных » («Error establishing a database connection »), тогда пропустите следующий шаг.

Однако если видите другое сообщение об ошибке, в котором говорится что-то вроде «…..The database may need to be repaired …» («Возможно, требуется восстановление базы данных »), тогда вы должны добавить следующий код в ваш файл wp-config.php :

define("WP_ALLOW_REPAIR", true);

Затем перейдите на вот эту страницу http://www.адрес_вашего_сайта/wp-admin/maint/repair.php .

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

Файл wp-config.php

Вы меняли ваш пароль администратора, или пароль к базе данных? Если да, вам также нужно внести изменения и в файл wp-config.php . Поэтому зайдите в ваш файл wp-config.php , и убедитесь, что данная информация верна:

define("DB_NAME", "database-name"); define("DB_USER", "database-username"); define("DB_PASSWORD", "database-password"); define("DB_HOST", "localhost");

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

Пообщайтесь со своим хостинг-провайдером

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

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

  • Сергей Савенков

    какой то “куцый” обзор… как будто спешили куда то