что делать если сайт перегружен
Диагностика проблем с «нестабильной доступностью» сайта
Представляю вашему вниманию статью, цель которой – определить последовательность действий при анализе нестабильной загрузки страниц или недоступности сайта для обычного пользователя. Кроме того, предлагаю дополнить мою схему общим умом хабрасообщества, поэтому жду ваших комментариев под постом, чтобы совместными усилиями сформировать «памятку для не-сисадмина».
Итак, приступим. 
Для начала, необходимо исключить из списка возможных неисправностей самые очевидные и легко диагностируемые: отсутствие подключения к Wi-Fi, проблемы на стороне интернет-провайдера или, например, отсутствие кабеля в розетке и аккумулятора в ноутбуке.
Предлагаю также опустить сложно решаемые проблемы и неисправности локального интернета или самого компьютера, которые требуют непосредственного вмешательства сисадмина. Это могут быть вирусы-трояны, проблемы с железом, браузером или операционной системой, MTU на роутере, неправильно настроенный DNS или сбои в работе DNS и ещё целый ряд проблем, которые выявить можно, но статья, в этом случае, превратится в книгу или даже в учебный курс.
Остановимся на том, что проблем с Интернетом у нас нет и сайты грузятся нормально, но вот наш сайт доступен с перебоями или недоступен вообще.
Как найти причину?
1. Интернет — это огромное количество магистралей, ведущих от сервера к серверу, и бывают случаи, когда наш сервер работает и мы видим другие сайты, но вот путь пакетов от нас к нашему сайту оборван: сегментировалась сеть из-за сбоя роутинга или где-то произошел сбой в работе каналов провайдеров. Конечно же, в консоли команда traceroute (tracert в Windows) покажет, доступен ли сервер нашего сайта, через какие сервера идут пакеты и на каком месте они «стопорятся». Если же traceroute и ping не доходят до нашего сервера, но достигают сети хостера, то самое время звонить в техподдержку хостинга или сисадминам, так как, в этом случае, сложно будет что-то предпринять самостоятельно.
Traceroute и ping – несложные команды, в Википедии есть статьи на эту тему с вполне доступным описанием:
https://ru.wikipedia.org/wiki/Traceroute
https://ru.wikipedia.org/wiki/Ping
Если traceroute «залипает» где-то на магистральных каналах по дороге к сайту, то рекомендую обязательно проверить, как виден сервер / сайт с других серверов (компьютеров) мировой сети вне вашего провайдера. Они, с большой долей вероятности, используют другие магистрали и зачастую бывает видно, что traceroute через другие каналы успешно проходит к вашему серверу. Например,
http://network-tools.com/default.asp?prog=express&host=www.reg.ru
Если всё в порядке, то проблемы либо у вашего провайдера, либо у его провайдеров уровнем выше, но не возле вашего сервера и не на нём.
Теперь можно позвонить в техподдержку вашего локального провайдера и поинтересоваться: «какие там магистральные каналы лежат?» 😉
2. Скорость и стабильность интернет-канала — это скорость и стабильность самого медленного и плохого канала связи на пути от вас к серверу. Определить, есть ли проблемы с потерями пакетов «по дороге», большие задержки пакетов между разными провайдерами или между вами и провайдером, можно с помощью утилиты mtr, а результаты утилиты особенно показательны при большом размере пакета и его возможной сегментации (например, 1500 байт).
Mtr – это что-то вроде совмещённых ping (опрос каждого сервера по пути следования пакетов) и traceroute (определение всего пути следования пакетов), но имейте в виду, что из-за постоянного потока пакетов утилита съедает достаточно много трафика.
Запрос проверки к сайту yahoo.com:
Показательным для нас будет значение процента потерь пакетов (Loss%) нашего, финального в списке, сервера. Потери на промежуточных серверах, если они не сказываются на финальном, скорее всего, происходят из-за ограничения количества тестовых пакетов к ним (ICMP-траффика).
Обычно, если имеется 30 – 50 % потерь больших пакетов, то проблемы с подключением уже становятся ощутимыми (страница «залипает», подтормаживает из-за недогруженных элементов), и чем выше процент, тем сложнее пробиться. 
Проблемы могут рождаться на каком-то промежуточном узле, например, на следующем магистральном Wi-Fi-линке от вашего офиса к провайдеру (если есть). К тому же, причиной могут стать проблемы в связи и роутинге пакетов между провайдерами.
С подробной статьей по использованию mtr для диагностики проблем с каналом (на английском) можно ознакомиться здесь или на Википедии.
Некое подобие утилиты mtr в Windows NT — pathping.
Иногда провайдером (или у нашего сервера) может быть вообще отключена или ограничена возможность прохождения этих тестовых пакетов (ICMP-траффика). В этом случае, такие тесты не помогут определить проблему. Тут уж, конечно, впору вспомнить про «каждый сам себе злобный буратино» — если вы отключаете возможность проверять сервер, то и не сможете его проверить :-).
При успешной загрузке (пусть и медленной) страницы сайта будет видно: когда загрузится основной контент страницы и она начнёт формироваться для отображения, когда начнут работать на сайте все вложенные java-скрипты, завязанные на работу с элементами страницы и ожидающие полной догрузки основного кода и необходимых неопределённых дополнительных вложенных элементов. Этот момент на картинке выше: синяя вертикальная линия – это событие DOMContentLoaded, а красная вертикальная линия – срабатывание windows.onLoad event (когда скрипты уже отработали и сформировалась вся страница в чем разница» rel=dofollow»>страница с элементами, догружается содержимое картинок).
С помощью этого информационного инструмента мы можем проверить, всё ли в порядке с загрузкой основного содержимого страницы и главного html-кода, то есть удостовериться, что наш сервер вполне «живой» и главный движок сайта не тормозит.
Это первый в списке элемент. Кликнув по нему, мы получим более детальное время ответа сервера:
Как мы видим здесь, наш браузер ждал данные от сервера 68 миллисекунд (сервер формировал страницу на полученный от нас запрос) и 2 миллисекунды она принималась (что достаточно быстро).
Уже по этой информации иногда можно увидеть, что проблема состоит в медленной загрузке сайта — это, например, не миллисекундное, а 30-тисекундное формирование основного кода страницы. Такое бывает, когда перегружен запросами сервер или провайдер, используется неэффективный код (долго работает конкретно запрос этой страницы) или существуют какие-либо другие причины, которые уже впору анализировать сисадминам и программистам движка.
Ниже в списке-графике загрузок будет видно, какие ресурсы на странице загружаются дольше, каких ресурсов страницы дожидается браузер перед тем, как показать страницу, и что блокирует её отображение.
Частая причина блокировок — это зависимость момента старта работы изменяющих / формируюших содержимое страницы (до привязки к событию DOMContentLoaded) скриптов от каких-либо внешних сервисов сбора статистики, рекламных движков или страниц обмена ссылками. Обычно это куски скрипта для вставки «ещё одного» внешнего скрипта:
Эти системы расположены на чужих серверах и зачастую недоступны нашим сисадминам, поэтому могут вести себя как угодно, например:
То есть, пока не подгрузится и не отработает блок
Почему сайт медленно загружается и что с этим делать
Сайт стал медленно открываться — с такой проблемой регулярно обращаются к нашим специалистам технической поддержки. У этой ситуации может быть много причин, и не сразу понятно, что проверять в первую очередь и где искать ошибки.
В статье рассказываем о девяти самых частых причинах медленной работы сайта и объясняем, как и с помощью каких инструментов все исправить.
Если ваш сайт создан с использованием HTML, CSS, JavaScript, PHP (или любого другого бэкенд-языка) — наши рекомендации наверняка окажутся полезными.
Проблемы с нагрузкой и ресурсами на хостинге
Если сайт стал медленно загружаться, первое, что нужно проверить — не потребляет ли он слишком много ресурсов на хостинге и нет ли превышения тарифных лимитов. Из-за этого могут возникнуть проблемы с веб-сервером.
Как проверить, сколько ресурсов потребляет сайт
Посмотрите статистику потребления ресурсов в панели управления хостингом. Если панель не показывает эти данные, запросите их у вашего хостера.
В панели управления хостингом RU-CENTER потребление ресурсов можно посмотреть в разделе «Статистика». Обратите внимание, сколько оперативной памяти и процессорного времени сайт потреблял за последние дни, неделю, месяц.
Вот как выглядит превышение ресурсов на графиках в панели управления хостингом RU-CENTER:
Потребление памяти в норме, потребление процессорного времени выросло
Потребление памяти и нагрузка на CPU (центральный процессор) выросли
Потребление памяти высокое, CPU в норме, но есть пик потребления
Также можно проверить логи доступа к сайту и посмотреть запросы за период высокого потребления ресурсов.
Чаще всего потребление ресурсов растет из-за следующих причин:
Некоторые владельцы сайтов переходят на более высокий тариф сразу же, как только замечают, что скорость снизилась, а расход ресурсов по тарифу превышен. Такой способ подойдет, например, когда очевидно, что посещаемость сайта выросла.
Но бывает, что посещаемость не изменилась, а ресурсы превышены и сайт тормозит. В таком случае переход на более высокий тариф может не решить проблему. Сначала лучше выяснить, что именно замедляет ваш сайт.
Проблемы с оптимизацией CSS и JavaScript
Когда пользователь переходит на сайт, браузер начинает собирать (рендерить) страницу, чтобы отобразить все ее элементы в окне браузера.
Рендеринг — сложный процесс. Браузеру нужно построить макет будущей страницы, понять, какие стили использовать для каждого элемента, отрисовать саму страницу.
Неправильно подключенные и настроенные файлы JavaScript и CSS могут замедлить рендеринг. Ведь браузер пытается сначала подгрузить скрипт, иначе содержимое страницы просто не отобразится.
Начните анализировать сайт с помощью инструмента PageSpeed Insights. Сервис изучит ваш ресурс, подскажет, что надо исправить и как изменения ускорят работу сайта.
Что делать, если замедляется рендеринг страницы
Как избежать ситуации, перегружен сервер, что делать немедленно
И так, будем избегать ситуации когда перегружен сервер и блог завис в отношение скорости загрузки.
Я ОБНАРУЖИЛ У ВАС БЛОКИРОВЩИК РЕКЛАМЫ!
Я понимаю, что Вы не можете выключить блокировщик рекламы. Просто потому что не хочется менять порядок вещей. Но как любой здравомыслящий человек, я хочу предложить компромисс.
Я ВАМ ПОДАРКИ! А ВЫ ОБРАЩАЙТЕ ВНИМАНИЕ НА РЕКЛАМЫ! БЕЗ ОБИД! БУДЬТЕ ЧЕЛОВЕЧНЕЙ ПО ОТНОШЕНИЮ К АВТОРАМ СТАТЬЕЙ! РАЗВЕ НЕ ПРИЯТНО, СДЕЛАТЬ КОМУ-ТО ДОБРО?
УВЕЛИЧИВАЙТЕ СВОЙ ПРОЦЕНТ ПОЛОЖИТЕЛЬНОЙ КАРМЫ. ВСЕ МЫ БУДЕМ БЛАГОДАРНЫ!
У нас на страницу минимум реклам. В начале статьи и в конце! Так что читать и познавать полезное, это ни как не помешает!
Добавьте этот веб-сайт в белый список или отключите программное обеспечение для блокировки рекламы!
ПОДАРКИ БУДУТ, ОСОБЫЕ, ПОДПИСЧИКАМ! ЭТО СДЕЛАТЬ ЛЕГКО И НЕПРИНУЖДЕННО. ТАКЖЕ, ПОДАРКИ БУДУТ ВСЕМ ДРУЗЬЯМ, КОТОРЫЕ НЕ ВКЛЮЧАЮТ БЛОКИРОВКУ РЕКЛАМЫ! И обращают внимание на рекламы.
ПОДАРОК найдешь над нижнем блоком (footer), или чтобы совсем понятно, сразу после комментариями. Конечно, когда отключишь блокировщик. Подарок будет обновляться и иметь разные тематики.
Малюсенький коллектив авторов уже благодарит ВАС, за доброту и понимание ситуации. В рекламах имеется полезная информация.
УДАЧИ ДРУЗЬЯ!
Вечный вопрос, как избежать упрека от менеджера хостинга, у вас перегружен сервер.
А это друзья бывает довольно часто.
Причины разные и про них мы будем с вами рассуждать, и главное будем решать проблему в самый корень.
А корень всех бед это работа вашего блога, сайта, интернет местечка без хеширование.
Надо установить плагин хеширования для WordPress.
А зачем это надо?
Потому что перед тем, как отобразить посетителю вашего блога одну из страниц, ее сначала необходимо сгенерировать, что создает дополнительную нагрузку на сервер.
При этом, чем больше посещаемость вашего блога, тем выше нагрузка и медленнее работает ваш блог.
Помни что медленная загрузка лишает вас части посетителей, а поисковики сильно понижают ваш сайт в выдаче. Поэтому позаботиться об этом лучше заранее, не дожидаясь, когда все станет совсем плохо.
Сразу и скажу, что перепробовал много разных вариантов хеширования. Долгие годы работал с собственным скриптом для хеширования.
Работает отлично, но после обновления WordPress или доработки теми приходится обновлять (в ручную) много разделов.
Лучше всего справится с этой проблемой вам поможет плагин «Hyper Cache».
А он запросто создает копии уже сгенерированных страниц. И при запросе страници передает их посетителям блога, минуя повторную генерацию.
Основные причины, по которым блог очень сильно нагружает хостинг:
• Постоянная проверка обновлений (как плагинов, так и ядра системы).
Каждый раз, когда Вы заходите в административную часть системы WordPress, система начинает проверять версии плагинов и ядра системы.
Делает она это, обращаясь к сайту плагина или сайту WordPress, и сравнивает версии. Обратите внимание, что даже Ваши неактивированные плагины проверяют наличие новых версий
• Отсутствие кэширования содержимого – если Вы сделали запись (пост) в Вашем блоге, то для каждого посетителя эта страница в чем разница» rel=dofollow»>страница будет генерироваться со стороны сервера.
• Большое количество ненужных виджетов – увеличивает время генерации страницы.
• Большое количество ненужных плагинов – плагины, работающие с базой данных, направляют в нее запросы, а также проверяют наличие новых версий.
• Множественные запросы к базе данных (вывод последних комментариев, последних новостей, самых популярных новостей/комментариев в отдельном блоке) – нагружает сервер.
• Множественные лишние запросы в самом шаблоне – потребляется большое количество ресурсов сервера для генерации страниц. Эти запросы можно заменить на статическое содержимое.
Оптимизация WordPress и снижение нагрузки.
Оптимизировать запросы от поисковых роботов:
Чтобы оптимизировать обращения поисковых роботов к Вашему сайту, необходимо разместить robots.txt. Файл robots.txt – это служебный файл, который подсказывает поисковому роботу, какие разделы сайта индексировать, а какие нет.
Например, нет никакой необходимости давать поисковым роботам индексировать раздел wp-admin.
Обратите внимание: нет существенной разницы, посещает Ваш сайт обычный пользователь или поисковый робот – потребление ресурсов будет одинаковым.
Так выглядит мой последний вариант 2020.года:
User-agent: *
Allow: /ads.txt
Disallow: /wp-admin
Disallow: /wp-includes
Disallow: /wp-content/plugins
Disallow: /wp-content/cache
Disallow: /wp-content/themes
Disallow: /trackback
Disallow: */trackback
Disallow: */*/trackback
Disallow: */*/feed/*/
Disallow: /*?*
Host: https://wp.kllproject.lv
Sitemap: https://wp.aspekti.eu/post-sitemap.xml
Sitemap: https://wp.aspekti.eu/page-sitemap.xml
Отмечу что строки, если таковы имеются :
Предположительно, все эти действия должны снизить нагрузку, которая создается в рамках Вашего аккаунта.
Пошли дальше, потому что есть много мероприятий для дальнейшего улучшения адекватной работы вашего сайта.
Дополнительные причины, по которым блог очень сильно нагружает сервер:
*Вывод последних комментариев(например на отображение 8 последних – а это дополнительные 8 запросов к БД)
* Вывод последних новостей в специальном блоке.
А зачем?
И так же на главной они выводится!
*Вывод самых комментированных новостей ( лишние запросы…)
* Большое количество совсем не нужных установленных виджетов.
Да, и сам грешу!
*Много не нужных установленных плагинов.
Теперь можно покопаться в шаблоне(находится в /wp-content/themes/имя_шаблона/).
Для этого скачаем редактор Notepad++, так как нам нужно работать в формате UTF-8 without BOM!
Вот полезный код для вставки в шаблон на время оптимизирования(чтобы узнать, сколько запросов к БД идет со страницы):
/
Начнем с файла header.php.
Открываем, как и договорились в блокноте Notepad++
Основной язык сайта, заменяем:
Примерно то что у вас:
>
Строка выбора кодировки страницы, меняем:
Примерно то что у вас:
; charset= ” />
Информация о движке :
Примерно то что у вас:
” />
Стили(таких строчек может быть много):
Если название блога точно определено, то меняем:
/”>
Вроде все, с файлом header.php закончили!
Если вы используете иконку сайта, а большинство это делают, то у вас в header.php наверняка есть такие строчки:
В поисках иконки система каждый раз обращается к базе данных. Тем самым притормаживая загрузку страницы.
Можно заменить на код, который позволит добраться до иконки в десять раз быстрее:
Иконку при этом положите в главную папку public_html
Еще парочка советов:
Вам не нужно комментирование на сайте? Отключайте Комменты в админке, и удалите все из файла comments.php.
По любому у вас есть облако меток – вместо плагина сохраните его как html код, и вставьте в страницу.
Вы не будете больше добавлять новые категории? – также сохраните их как html и вставьте вместо виджета!
В файле single.php у многих шаблонов название новости – ссылка на эту же новость. Зачем это?
Не отображайте на страницах большое количество новостей, это сильно грузит.
Ну и совсем не лишнее проверка работы htaccess и с его помощи сжатие для ускорения сайта
laimisk
Добавить комментарий Отменить ответ
Подпишитесь! На нашу рассылку! Мы храним ваши данные в сохранности!
Подтверждение подписки обязательно!
Иначе, попадайте в папку неподтвержденный.
А это в итоге, НЕПОЛУЧЕНИЕ новостей и подарков!
Из последнего, что получили подписчики!
Сенсация в медицине!
Здесь собраны книги о нашем здоровье, написанные настолько просто и увлекательно, что пройти мимо просто невозможно.
ОТЛИЧНЫЙ СЕРВЕР!
(Реклама)
РЕКОМЕНДУЮ!
Работает на отлично! Мой
опыт использования сервера!
Последнее, что опубликовано
Если вам интересно на нашем сайте … я рад!
ВСЕ СТАТЬИ, читаем и вникаем!
Полезно для блогера и для Тебя, кто нашел жилку творчества в интернете.
В ПОДАРКЕ: С Новым Годом! Также Рождественские песни! В хорошем качестве, как иначе!
Автообновление страницы сайта: где и как отключать в браузере
На некоторых сайтах (а их довольно много) страницы «умеют» сами обновляться и перезагружаться. В ряде случаев автообновление страницы — вполне себе оправданное и нужное решение. Правда, зачастую только с точки зрения вебмастера.
А вот пользователю такого сайта постоянные перезагрузки страницы могут и не понравится, мягко говоря. В особенности, если остановить их никак нельзя. В смысле, что отдельного выключателя нигде не видно.
Посему расскажем мы о том, как с этим бороться безо всяких кнопок, то бишь как блокировать автообновление веб-контента в Google Chrome, Mozilla Firefox, Internet Explorer и Microsoft Edge.
Метод, к слову, работает и в «родственных» браузерах: в Pale Moon и Waterfox (настраивается, как и в Firefox), а также в Vivaldi и Opera (как и в Chrome).
как отключить автообновление страницы в Chrome
В самом супер-пупер-мега-популярном браузере в мире ни отдельной кнопочки, ни даже специальной опции в настройках, с помощью которых можно было бы выключить автоматическую перезагрузку веб-страницы, НЕ ПРЕДУСМОТРЕНО.
Более того, и из всех расширений с подходящим функционалом более-менее прилично работает фактически лишь Auto Refresh Blocker (линк)- 2.33 звездочки из 5. Низкий рейтинг расширения, надо понимать, обусловлен тем, что на некоторых сайтах оно попросту не работает.
Тем не менее, Auto Refresh Blocker отключать элементы на страницах большинства сайтов таки может. Кроме того, оно также может и блокировать заголовок HTTP «refresh» и позволяет юзеру создавать собственный «черный список» запросов и сайтов. И это все же лучше, чем вообще ничего.
Если же без расширений, то остается только блокировать автоперезагрузку каждого отдельного сайта «вручную» через «Инструменты разработчика» Chrome.
Для этого в браузере жмем F12, на панели открываем вкладку Console, в поле ниже вводим команду window.onbeforeunload = function() и жмем Enter. Команда эта универсальная и точно также работает в других браузерах.
как отключить автообновление страницы в Firefox
А вот в этом браузере нужный нам «выключатель» есть. И хотя он находится не в открытой части интерфейса и даже не на странице «Настроек«, блокировать автоперезагрузку страниц в Firefox гораздо проще, чем в Chrome.
Делается это следующим образом: в поисковую строку копируем about:config?filter=accessibility.blockautorefresh, жмем Enter (предупреждение, если таковое появится, пропускаем) и в следующем окне двойным кликом по строке accessibility.blockautorefresh меняем её значение с false (по умолчанию) на true. Это всё.
Данный параметр определяет статус функции автообновления контент в браузере (статус блокировки элемента http-equiv=»refresh» и заголовков HTTP «refresh»).
Попутно можно точно так же включить функцию browser.meta_refresh_when_inactive.disabled, чтобы страницы не перезагружались и в неактивных вкладках Firefox.
как отключить автообновление страницы Internet Explorer
В IE выключить можно только функцию метаообновления контента, притом делается это в настройках безопасности браузера:
как отключить автообновление страницы в Microsoft Edge
На данный момент времени никак. В Edge такая возможность не предусмотрена. И специального расширения для этого тоже еще не сделали. Ни одного. Так что, пользователю Edge автообновление контента придется либо терпеть, либо просто поставить на комп еще один браузер…
Причины перегрузки сайта
Posted By: admin 29.11.2018
Перегрузка сайта
Перегрузка происходит тогда, когда один процесс захватывает один или несколько ресурсов на длительный срок, в результате чего другие процессы выстраиваются в очередь, и весь хостинг замедляет свою работу, и есть риск, что работа может остановиться. Чтобы этого не произошло, на хостингах производят периодические блокировки сайтов, занявших слишком много ресурсов, пишут гневные письма владельцам сайтов и грозятся разорвать договор, если причина перегрузки не будет устранена.
Причин перегрузки несколько:
— Чрезмерная активность поисковых роботов
— Высокая посещаемость ресурса
— Программные коды низкого качества
Среди файлов, размещенных на платном хостинге, всегда есть логи, в которых в простом текстовом формате записано, какой IP, когда, куда и с какой страницы заходил, так что первые две причины необходимо выявлять именно на основе логов, которые фиксируют как посетителей-людей, так и ботов. Проверка логов выявила, что мой сайт был заблокирован по первой и третьей причинам одновременно, отчасти, быть может, и по второй. Чересчур активные поисковые роботы полезли на страницу регистрации и входа на сайт, на который можно зайти не только с помощью обычной регистрации, но и с помощью плагина Loginza, который, видимо, оказался тяжелым, если его активизировать много раз одновременно.
Трудно сказать, сильно ли повлияла посещаемость сайта, но могла повлиять. Судя по логам, DDOS-атак не было, но изначально, создавая блог, я рассчитывала на посещаемость в 100-200 человек в день, однако она превысила мои ожидания, а в последние дни и вовсе достигла 2500. В моем блоге есть несколько докладов о космосе, которые вдруг всем понадобились в преддверии 50-летия Дня Космонавтики и немногим позже.
Установить причины проблемы — это полдела. Осталось применить меры. Плагин Loginza мне удалять не хочется, потому что он позволяет зайти в блог как по OpenID, так и с помощью распространенных ныне аккаунтов ВКонтакте, Facebook, Яндекс, Google, Twitter и других. Поэтому я прибегла к другой мере — установила лимит захода поисковых роботов в блог и закрыла от них страницу входа и регистрации.
Для этого нужно создать файл robots.txt, находящийся в корневом каталоге WordPress. Этот файл содержит указания для поисковых роботов. У меня уже был этот файл, он содержал запрет поисковым ботам заходить в админку. Осталось дополнить и разнообразить этот файл, и теперь он выглядит так.
User-agent: *
Disallow: /wp-admin
/wp-includes
/wp-login.php
Crawl-delay: 3
Строка User-agent содержит указания, для какие поисковых роботов действуют указания. Звездочка * означает, что они действуют на все боты.
Disallow — запрет на индексацию. Блокируем доступ к страницам, начинающимся с /wp-admin, /wp-includes, и к странице входа и регистрации.
Crawl-delay задает паузу в секундах для поисковых роботов.
Теперь файл robot.txt помещается в корневой каталог WordPress.
Кроме этого, рекомендуется установить плагин WP Super Cache, который генерирует статические html-файлы, периодически обновляемые, в результате чего тяжелые скрипты должны выполняться реже.