Сейчас я расскажу как мне наконец-то удалось снизить CPU нагрузку от моих сайтов wordpress на хостинге. Длилась эта история 3 месяца. Показатель CPU в моём аккаунте был итак на пределе и вдруг начал совсем зашкаливать.

Сколько я прочитала статей в интернете, и сколько облазила форумов — сама точно не знаю. Что я сделала за это время на своих сайтах.

• Минимизировала количество плагинов. Особенно надо обратить внимание на тяжёлые плагины со сложными скриптами. Обнаружить таких обжор вы можете при помощи плагина P3 (Plugin Performance Profiler)
• Уменьшила вес картинок. Количество тоже желательно уменьшить, но как без скриншотов, ведь будет сложно понять о чём идёт речь
• Поставила плагин кеширования — Hyper Cache
• Уменьшила нагрузку, которую создают поисковые боты

Но только моим сайтам это не помогало, как слону дробина. Проклятое CPU уже показывало более 40-50 единиц, хотя на моём тарифе допускалось – 30. Мой хостер — webhost1 , меня не беспокоил. Но зато психовала я, тем более, что в один прекрасный день мои сайты автоматически отключились – правда длилось это несколько минут. И пришлось перейти на более дорогой тариф.

А CPU на хостинге стало зашкаливать в некоторые дни даже за 50. Переходить на другой хостинг? Возня неимоверная, тем более что на Вебхосте я уже более 3-х лет. И где гарантия, что там история не повторится или не будет ещё хуже. Оставалось только закрывать сайты или платить нереальную (неокупаемую) цену. Но делать этого не хотелось и пошла я бродить по своей хостинг панели.

И о чудо, метод научного тыка как всегда помог! Зашла я в домены и сравнила PHP сайтов старых и новых. Оказалось, что старые сайты работали на устаревшей версии PHP5.3, а новые на PHP5.6!!! Переключила я своих «старичков» на PHP5.6 и уже третий месяц сплю спокойно. CPU нагрузка на хостинг — стабилизировалась.

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

В Настройках найти PHP, выбрать версию 5.6 нажатием на треугольник. И сохранить. После этого нагрузка на CPU должна снизиться. Только не выбирайте версию 7.0 , иначе у вас могут исчезнуть картинки и тема сайта.

• Не забывайте чистить базу данных каждую неделю. Плагинами: и .
• Загружать новые обновлённые версии плагинов и движка Вордпресс. Особенно если у вас не отключены обновления – этого, кстати, делать и не рекомендуется, хотя в сети встречаются статьи с советами отключать обновления. Якобы этот способ сильно снижает нагрузки – снижает, но не более чем на 3-5 единиц! А вот сайты свои вы подвергаете опасности быть взломанными, так как в каждой новой версии движка или плагинов закрываются уязвимости. Поэтому заходите хотя бы раз в неделю на свои сайты и принимайте обновления.

Рада, если смогла вам помочь и перед вами больше не стоит вопрос Как снизить нагрузку на CPU хостинга.

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

нам приходят на помощь дополнительные инструменты под названием плагины - рабочие лошадки, помощники в работе наших блогов. Что бы мы без них делали? Чтобы улучшить и ускорить загрузку блога, установим простенькие плагины для для оптимизации и ускорения загрузки блога. В сегодняшней статье установим плагин для чистки территории блога WP -Optimize. Как устанавливать плагины,

Плагины для оптимизации wordpress
1 - WP-Optimize помогает оптимизировать базу данных и таблицы сайта. Это обязательно - необходимый плагин.
Функции WP - Optimize:

• Конкретно чистит наш ресурс от всяческого мусора.
• Оптимизирует - сжимает базу данных блога и таблицы.
• Удаляет все резервные копии записей, когда мы ставим статью на блог и по несколько раз редактируем один и тот же пост, также весь опубликованный контент.
• Удаляет спам комментарии.
• Не конфликтует с другими плагинами.
• Просто и стандартно устанавливается на блог.
• Входим в админку
• Плагины
• Добавить новый
• В поисковой строке вписываем название WP-Optimize
• Устанавливаем
• Активируем

Далее еще проще: В меню слева ищем по названию WP-Optimize, заходим в настройки, видим фото людей, которые отблагодарили лайком.
Жмем лайк Нравится - отправляем на Фейсбук, лайк не отправите, плагин будет молчать и работать не начнет. Как немой и глухой ничего не слышит, так и этот плагин будет бездействовать. Со мной такая история

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

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

Акисмет переусердствовал - он же надежный охранник блога от спамщиков, загнал несколько комментариев для подстраховки в спам - папку. Отрабатывает свой хлеб. :)
А теперь можно чистить. Ставим во всех пунктах чебоксы - птички и жмем слово PROCESS.

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

После чистки плагин деактивируем и один раз в 5 - 7 дней чистим территорию блога.
2. Следующий плагин классический, который не нужно настраивать - по умолчанию он сам знает свои функции от а до я. Для этого постарался автор плагина Макаров, а плагин я нашла на сайте Дмитрия Сидаш sidash.ru/ у которого очень часто прогуливаюсь в поисках интересной и полезной информации. Заходите и вы - многое для себя почерпнете.

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

Какую пользу имеем от этого плагина:

• Отключает проверки обновлений тем, плагинов, движка
• Отключает автосохранение редактируемой записи
• Включает автоматическую оптимизацию и восстановление Базы данных
• Отключает ревизии постов
• Отключает генераци метатегов
• Подгружает AJAX библиотеки с сайта google, для пользователей
• Снижаем нагрузку на сервер благодаря плагину
• Семь функций защищают сайт от спама
• Запрет в комментариях активных ссылок

Устанавливается аналогично всем плагинам.

Домен не исчез, сайт на месте, но этого плагина нет. Ссылки на разные темы... При нажатии на ссылку автора появляется запись:

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

Появился сайт в сети, даже не знаю - когда, но почему - то сейчас находится в АГС. Ссылка будет здесь неактивной http://makarou.com/ssd-optimize-wordpress-5-0. Как скачать данный плагин: Выделяем ссылку http://makarou.com/ssd-optimize-wordpress-5-0, копируем, вставляем в адресную строку. Но выше цитаты ссылка активная, скачивайте и устанавливайте.

Информация о плагине

Все выполняемые функции

Статистика по комментариям и трекбэкам

Мой скайп gvozdika571
Всегда рада видеть вас у себя на блоге

Здравствуйте, уважаемые читатели блога сайт. C Наступившими Вас праздниками!

В этот промежуток времени (где-то около получаса) админка выдает 502 ошибку, а для посетителей сайт хоть и доступен, но страницы открываются довольно медленно (от 5 до 15 секунд). Если бы кеширование на блоге не использовалось, то и они бы выдавали 502 ошибку. Помогает только либо двукратная перезагрузка сервера, либо тупое ожидание пока все само собой рассосется.

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

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

Немного погуглив я понял, что «это» появилось в WordPress 4.4 и нужно для чего-то (пока смутно представляю для чего — если в курсе, то поясните). Т.к. «это» появилось недавно, то особо много рецептов удаления нагуглить не удалось, а то, что нашлось, работало как-то кривенько (первая ссылка удалялась, но две другие нет, и вести они стали на ту же страницу, код которой был открыт).

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

Помимо этого в исходном коде был еще и сильно бросающийся в глаза блок:

Помню, что он был и раньше. Помню, что я якобы знал раньше, откуда он взялся, но сейчас сколько ни пытался, никак не мог вспомнить или даже зацепиться за то, откуда это «красота» появилась в шапке блога (на других блогах он тоже присутствовал). Немного мысленно побуксовал я уперся взглядом в слово emoji в коде. Недавно писал . Чуток погуглил и убедился, что таки да — этот код помогает отображать на страницах WordPress эти самые эмодзи смайлики .

Так как emoji смайлы у меня выводятся от силы в двух-трех статьях, то решил это безобразие убрать, для чего и был произведен поиск рецепта в сети. Решение, как всегда в таких случаях, состояло в добавлении фильтров из папки с используемой вами темой оформления WordPress. В общем, находим в нем место окончания какой-нибудь функции (точку с запятой) и туда добавляем несколько строк непонятного (мне), но вполне себе работающего кода:

Remove_action("wp_head", "print_emoji_detection_script", 7); remove_action("admin_print_scripts", "print_emoji_detection_script"); remove_action("wp_print_styles", "print_emoji_styles"); remove_action("admin_print_styles", "print_emoji_styles"); remove_filter("the_content_feed", "wp_staticize_emoji"); remove_filter("comment_text_rss", "wp_staticize_emoji"); remove_filter("wp_mail", "wp_staticize_emoji_for_email");

Это вариант самого полного отключения поддержки эмодзи в WordPress . Хотите в админке оставьте . Все, после этого наступило приятное чувство чистоты кода от всяко разного.

На тех страницах, где я эмодзи все же использовал, пришлось чуток подправить текст. Я просто открыл эти статьи на редактирование в админке и прямо в самом начале (в Html редакторе, а не в визуальном) добавил этот самый код, который удалил из шапки всех страниц:

window._wpemojiSettings = {"baseUrl":"http:\/\/s.w.org\/images\/core\/emoji\/72x72\/","ext":"..min.js?ver=4.4"}}; !function(a,b,c){function d(a){var c=b.createElement("canvas"),d=c.getContext&&c.getContext("2d");return d&&d.fillText?(d.textBaseline="top",d.font="600 32px Arial","flag"===a?(d.fillText(String.fromCharCode(55356,56806,55356,56826),0,0),c.toDataURL().length>3e3):("simple"===a?d.fillText(String.fromCharCode(55357,56835),0,0):d.fillText(String.fromCharCode(55356,57135),0,0),0!==d.getImageData(16,16,1,1).data)):!1}function e(a){var c=b.createElement("script");c.src=a,c.type="text/javascript",b.getElementsByTagName("head").appendChild(c)}var f,g;c.supports={simple:d("simple"),flag:d("flag"),unicode8:d("unicode8")},c.DOMReady=!1,c.readyCallback=function(){c.DOMReady=!0},c.supports.simple&&c.supports.flag&&c.supports.unicode8||(g=function(){c.readyCallback()},b.addEventListener?(b.addEventListener("DOMContentLoaded",g,!1),a.addEventListener("load",g,!1)):(a.attachEvent("onload",g),b.attachEvent("onreadystatechange",function(){"complete"===b.readyState&&c.readyCallback()})),f=c.source||{},f.concatemoji?e(f.concatemoji):f.wpemoji&&f.twemoji&&(e(f.twemoji),e(f.wpemoji)))}(window,document,window._wpemojiSettings); img.wp-smiley, img.emoji { display: inline !important; border: none !important; box-shadow: none !important; height: 1em !important; width: 1em !important; margin: 0 .07em !important; vertical-align: -0.1em !important; background: none !important; padding: 0 !important; }

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

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

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

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

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

Удачи вам! До скорых встреч на страницах блога сайт

Вам может быть интересно

Пропало левое меню в админке WordPress после обновления Где скачать WordPress - только с официального сайта wordpress.org
Установка WordPress в деталях и картинках, вход в админку WP и смена пароля Пустая страница при просмотре больших постов (статей) в WordPress
Снижение потребляемой в WordPress памяти при создании страниц - плагин WPLANG Lite для подмены файла локализации
Как войти в админку WordPress, а так же поменять логин и пароль администратора выданные вам при установке движка

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

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

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

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

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

Жесть, не правда ли? Да что тут говорить, помимо такой «скорости», и доступность сайта хромала, порой сайт открывался через раз. Одним словом он катастрофически зависал и отказывался полноценно работать. А самое интересное заключалось в том, что при авторизации в админ-панели проблем становилось ещё больше!

Это вызвало у меня ещё больше интереса, потому что я никогда не ранее не сталкивался с подобным! «Ну что ж, попробуем, чем тяжелее — тем интереснее» — подумал я, и приступил к работе.

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

Таким образом я обнаружил 2 плагина, которые грузили блог значительнее остальных, это LeadPages и NextGEN Gallery. Но после их отключения и очистки кэша абсолютно ничего не изменилось. И тогда началось самое интересное. Я начал копать всё глубже и глубже, дабы выискать истинную причину сего безобразия 🙂

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

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

И помимо этого, прекратились постоянные сбои в работоспособности и хостеры перестали жаловаться на повышенную нагрузку CPU. Ура! К чему стремился, то и получил — миссия выполнена.

Но что именно я делал и как мне удалось одержать победу? Давайте по порядку.

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

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

2. Зачастую тормоза появляются из-за скрипта под название WP-Cron . Данный скрипт, встроенный в WordPress отвечает за планирование задач. К примеру, размещение статей по времени, автоматическая чистка корзины, создание резервной копии с помощью плагина и т.д.

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

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

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

1 способ. Переходим в корень Вашего сайта по Ftp, например через FileZilla, и открываете там файл под названием wp-config.php и добавляем новую строчку:

Define(‘DISABLE_WP_CRON’, true);

Желательно добавить её после строки:

Define(‘WPLANG’, ‘ru_RU’);

После чего сохраняете файл и радуетесь, скрипт должен отключиться.

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

2 способ. Опять же, в корне сайта необходимо открыть файл под название wp-cron.php , найти строчку:

Ignore_user_abort(true);

и закомментировать её (отключить) с помощью двух слэшов. На выходе должно получиться вот так:

//ignore_user_abort(true);

Сохраняем файл и cron отключается.

3. Далее, необходимо включить zlib компрессию , которая позволяет значительно ускорить сайт за счет обработки и сжатия php кода. В первую очередь Вам необходимо написать хостеру и узнать включен ли у Вас функция zlib или же нет. Если подключена — отлично, если же нет — просим включить. После чего переходим в файл header.php и в самый самый верх вставляем следующий код:

Сохраняем файл и ощущаем значительный прирост в скорости.

4. После чего очень важно оптимизировать БД с помощью плагина . Переходим в админ-панель, открываем вкладку «Плагины» — «Добавить плагин» и в поиске вбиваем «WP-Optimize», нажимаем Enter и устанавливаем первый плагин.

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

5. Теперь наша задача защитить блог от Ddos-атак , т.к. именно такие атаки зачастую и становятся причиной «сноса мозгов» сайта. Для этого, во-первых, я рекомендую установить плагин под названием iThemes Security, про его настройку я расскажу в следующей статье, а во-вторых, важно использовать блокировку подозрительных посетителей с помощью .htaccess .

Я не буду сейчас объяснять как выискивать таких подозрительных и вредоносных , потому что это тема отдельной статьи, а поделюсь с Вами списком IP-адресов, которые я сумел собрать за некоторое время. Именно их и нужно будет заблокировать.

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

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

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

Определив, что источником нагрузки является wp-cron.php, его можно отключить, добавив в файл wp-config.php строчку:

Define("DISABLE_WP_CRON", true);

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

Wget http://ваш_сайт.ру/wp-cron.php?doing_wp_cron > /dev/null

В WordPress есть скрипт xmlrpc.php, он отвечает за вызов удаленных процедур и поддерживает известные API - WordPress API, Blogger API, MetaWeblog API и MovableType API. С помощью этого файла можно удаленно публиковать посты на своем сайте или полностью им управлять, не обязательно через административную панель. И как раз таки частые запросы к XMLRPC могут вызывать чудовищную нагрузку, что очень эксплуатируется на практике.

Если Вы вообще не используете в своей работе XMLRPC (а этого наверняка Вы не делаете), то можно просто удалить из корня своего сайта файл xmlrpc.php. А чтобы боты не грузили 404 страницу, в.htaccess добавляем редирект на microsoft.com (сервера у них хорошие):

Redirect /xmlrpc.php http://www.microsoft.com

wp-login отвечает за авторизацию на сайте WordPress. Слишком частое к нему обращение, например, в целью подобрать пароль администратора, что осуществляется программно, вызывает сильную нагрузку. Избежать нагрузок можно, заменив это стандартное имя. Сделать это можно множеством способов, вот пример с плагином и без плагина.

в.htaccess добавляем:

Order Deny,Allow Deny from all

Файл wp-login.php, переименовываем в секретное имя, например cudanelza.php и внутри файла меняем все надписи wp-login.php на cudanelza.php.

Теперь у нас wp-login.php стал cudanelza.php

Плагины - Добавить новый - ищем "Lockdown WP Admin". Ставим, активируем, переходим в настройки. Напротив "Yes, please hide WP Admin from the user when they aren"t logged in" ставим галочку. В разделе WordPress Login URL прописываем новый адрес админки, например, "parapara". Сохраняем настройки. Теперь наша админка доступна по адресу http://сайт.ру/parapara

XML карту сайта в WordPress генерируют плагины. Но многие игнорируют тонкие настройки плагинов, в результате чего, в sitemap попадает различный технический мусор. В sitemap.xml генерируется коллосальное количество страниц, ненужных для индексации, но тем, не менее, предлагаемых для обхода роботами. В таких ситуациях роботы могут создать коллосальную нагрузку на сервер, постоянно выкачивая не нужные страницы.

Вот как выглядят дефолтные (по умолчанию) настройки XML карты сайта в плагине All in One SEO. В XML карту попадают все типы записей, которые там вообще не нужны:

Дефолтные настройки XML карты сайта в плагине All in One SEO

Именно дефолтные настройки XML карты сайта были частой причиной нагрузки на сервер, вызываемой поисковыми ботами и пауками.

Данная проблема решается в несколько этапов:

1. Настройте sitemap.xml таким образом, чтобы сюда попадали исключительно ссылки на страницы/записи вашего сайта

2. В robots.txt пропишите директиву

Crawl-delay: 10

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

3. Блокируйте ненужных Вам роботов. В статье вы найдете действенные методы блокировки ненужных ботов и пауков

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

P.S. В WordPress имеются недостатки, которые рано или поздно могут привести к нагрузке на вашем сервере. Этими недостатками могут воспользоваться недоброжелатели, что чревато выходом за предоставленные хостингом лимиты. Надо быть готовыми к их устранению. Наиболее частые проблемы мы только что рассмотрели. Также в связи с этим напрашивается закономерный вопрос: почему озвученным аспектам так мало уделяют внимания разработчики WordPress? Это не проблема последних версий, а наиболее уязвимые места, которые передаются по наследству, от версии к версии! Разумеется, с помощью плагинов и обширного кодекса, WordPress можно адаптировать под практически любые нужды вебмастера, но вебмастерами зачастую выступают новички, поэтому хотелось бы видеть механизмы защиты обозначенных в этой статье проблем в дефолтных сборках WP. Тогда и взломов сайтов было бы меньше и нагрузок на серверах поубавилось!

Вконтакте