Allow wp admin admin ajax php: seo — Why does do_robots() Allow: /wp-admin/admin-ajax.php by default?

Правильный robots.txt для Вордпресс

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

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

Robots.txt — это текстовый файл, находящийся в корневой директории сайта, в котором записываются специальные инструкции для поисковых роботов, разработан Мартином Костером и принят в качестве стандарта 30 июня 1994 года.

Robots.txt — мощное оружие SEO-оптимизации, грамотная настройка которого может существенно помочь в индексации.

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

Еще недавно Google был настолько примитивен, что видел сайты лишь в виде HTML-кода. В прошлом году, с приходом алгоритма Panda 4, Google стал видеть сайты такими же, какими их видят пользователи. Вместе с CSS и исполненным JavaScript.

Это изменение коснулось и Вордпресс.

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

Получается, что старая практика больше не работает.

На многих Вордпресс-сайтах закрывалась от индексации и другая системная директория /wp-admin/. Что правильно, по-сути. Но если на сайте используется асинхронная загрузка страниц (AJAX), это может блокировать загрузку внутренних страниц. Потому что admin-ajax.php, который за всё это отвечает, расположен в /wp-admin/.

Директорию

/wp-admin/ можно оставить закрытой от индексации, но тогда необходимо отдельно разрешить индексацию admin-ajax.php.

Allow: /wp-admin/admin-ajax.php

Если в вашем Вордпресс используется один из старых способов оформления robots.txt, нужно обязательно проверить какие конкретно директории скрываются от индексации и удалить все запреты, блокирующие загрузку страниц.

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

Как проверить Robots.txt

Проверить robots.txt на ошибки можно с помощью инструмента проверки файла robots.

txt — именно так и называется этот инструмент в разделе «Сканирование» Google для веб-мастеров.

Кстати, проверить robots.txt на ошибки можно и в Яндекс Вебмастере. Но в Google Search Console все равно нужно зарегистрироваться, потому что только там можно проверить видимость сайта поисковыми пауками Гугла. Конкретно это делается в разделе «Сканирование» с помощью инструмента «Просмотреть как Googlebot».

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

Как же должен выглядеть правильный Robots.txt для Вордпресс

Я все больше убеждаюсь, что лучше делать сразу минимальный robots.txt и закрывать только /wp-admin/. Естественно, открыв admin-ajax.php, если есть AJAX-запросы. И обязательно указываем Host и Sitemap.

Мой robots. txt чаще всего выглядит так:

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Host: https://danilin.biz
Sitemap: https://danilin.biz/sitemap.xml

В заключение

Создать универсальный правильный robots.txt для всех сайтов на Вордпресс невозможно.

На каждом сайте работает конкретная тема, набор плагинов и типов данных (CPT), которые генерируют свой уникальный пул URL.

Robots.txt часто корректируется уже в процессе эксплуатации сайта. Для этого осуществляется постоянный мониторинг индекса сайта. И если в него попадают какие-то ненужные страницы, они исключаются. Например, в индекс иногда попадают страницы с параметрами ?p и ?s.

Их можно исключить.

Disallow: /?p=
Disallow: /?s=

Иногда даже попадают фиды, которые тоже можно закрыть.

Disallow: */feed

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

Для Яндекса инструкции в robots.txt и метатег «noindex» работают одинаково — страница удаляется из индекса. А вот для Гугла robots.txt — это запрет на индексирование, а метатег «noindex» — запрет на сканирование. И если, допустим, страница заблокирована в robots.txt, поисковый робот может просто не обнаружить метатег «

noindex» на этой странице, и она останется в индексе. Об этом прямо написано в Справке Search Console.

Как видим, Robots.txt может быть очень опасен для сайта.

Бездумные действия с этим файлом могут привести к печальным последствиям. Не спешите с помощью него закрывать все подряд директории. Пользуйтесь плагином Yoast SEO — он позволяет настроить правильные запреты с помощью метатегов.

seo — Почему do_robots() разрешает: /wp-admin/admin-ajax.php по умолчанию?

Это происходит со свежей новой установкой WordPress.

Но все, что вам нужно сделать, это посмотреть на сумасшедшую функцию do_robots(), которая выводит следующее…

 User-agent: *
Запретить: /wp-admin/
Разрешить: /wp-admin/admin-ajax.php
Карта сайта: https://knowingart.com/wp-sitemap.xml
 

Отправка роботов в «wp-admin» (по умолчанию) не имеет смысла:

1. Зачем мне отправлять случайных роботов в мой каталог администратора?! Каталог admin для меня и только для меня. Роботы/краулеры не должны находиться в моем каталоге администратора и ничего не делать.
2. Зачем мне DOS атаковать себя, отправляя роботов в скрипт администратора?
3. Если бы я был разработчиком бота, я мог бы (ошибочно) интерпретировать это «разрешить» как отрицание запрета, потому что разрешение идет после запрета и это тот же каталог. Почему robots.txt здесь противоречит сам себе?
4. Этот странный файл robots.txt (по умолчанию), кажется, ломает DuckDuckGo. Например, лучшим результатом поиска является мой каталог wp-admin?! Похоже, что DuckDuckGo прочитал мой robots. txt, зашел в wp-admin, потому что robots.txt сказал ему перейти туда, а это неправильный каталог. Был ли сканер DDG сбит с толку странным файлом robots.txt? Теперь я думаю, что DDG просканировал мой блог до того, как какой-либо контент был доступен, и просто еще не обновился, это кажется более вероятным объяснением.

Почему WordPress отправляет поисковые роботы в каталог администратора, в котором нет содержимого?! Для меня это не имеет смысла, поэтому я здесь пытаюсь понять это. Я могу только представить, что автор этого кода do_robots() не понимает назначения robots.txt

• wp-admin
• seo
• хостинг
• robots.txt

6

Во-первых: прочтите robots.txt, если вы еще этого не сделали. Еще один хороший референс от Yoast.

Образец, который вы разместили:

 User-agent: *
Запретить: /wp-admin/
Разрешить: /wp-admin/admin-ajax.php
Карта сайта: https://knowingart.
  com/wp-sitemap.xml
 

… сообщает всем пользовательским агентам (т. е. всем поисковым роботам), что им не разрешено сканировать что-либо в вашем каталоге wp-admin кроме /wp-admin/admin-ajax.php , который требуется WordPress для правильной работы AJAX.

Это , а не говорит роботам идти к вам /wp-admin/ каталог ; это говорит им, что они там нежелательны (за исключением требования AJAX).

Что касается вашего вопроса №4, боюсь, у меня нет на него ответа.

5

правда в том, что, вероятно, ничто не должно быть заблокировано в robots.txt ядром (это IIRC была позицией Джоста по этому вопросу), поскольку WordPress является открытой платформой, а интерфейсный контент и стиль могут генерироваться во всех видах каталоги, которые могут не иметь большого смысла для нас с вами. WordPress не занимается предотвращением установки владельцами сайтов плохо написанных плагинов.

Почему у вас есть страницы, проиндексированные поисковой системой? WordPress использует своего рода заголовки «не индексировать» для всех страниц администратора, поэтому, скорее всего, у вас есть плохо написанный код, который препятствует отправке заголовка. (это предполагает, что в bing, который является SE, на котором работает DDG, нет ошибки).

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

3

Зарегистрируйтесь или войдите в систему

Зарегистрируйтесь с помощью Google

Зарегистрироваться через Facebook

Зарегистрируйтесь, используя электронную почту и пароль

Опубликовать как гость

Электронная почта

Требуется, но никогда не отображается

Опубликовать как гость

Электронная почта

Требуется, но не отображается

Нажимая «Опубликовать свой ответ», вы соглашаетесь с нашими условиями обслуживания, политикой конфиденциальности и политикой использования файлов cookie

.

WordPress Heartbeat и Heavy admin-ajax.php Использование

Обновлено Джеффом Мэтсоном 10 марта 2023 г.

5 минут, 29 секунд на чтение веб-браузер и сервер. Это позволяет улучшить управление сеансом пользователя, отслеживание изменений и автоматическое сохранение.

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

WordPress Heartbeat API использует /wp-admin/admin-ajax.php для выполнения вызовов AJAX из веб-браузера. Что в теории звучит потрясающе, поскольку WordPress может отслеживать, что происходит на панели инструментов.

Однако это также может привести к отправке чрезмерных запросов на admin-ajax.php , что может привести к высокой загрузке ЦП. Каждый раз, когда веб-браузер остается открытым на странице с использованием Heartbeat API, это потенциально может быть проблемой.

• WordPress Heartbeat API в действии
• Отключение WordPress Heartbeat API
  • Установка плагина Heartbeat Control
  • Настройка плагина Heartbeat Control

WordPress Heartbeat API в действии

Нечто, обрабатываемое WordPress Heartbeat API, — это главная страница административной панели WordPress. Если все, что вы сделали, это вошли в WordPress, а затем свернули это окно и начали работать над чем-то другим, вы увидите запросы на admin-ajax.php в журналах доступа вашего сайта.

В [00:29:30] я вошел в панель управления, и вы можете увидеть первоначальный запрос GET /wp-admin/index.php.

Затем в [00:30:31] WordPress Heartbeat API отправляет запрос POST /wp-admin/admin-ajax.php Heartbeat.

Когда в фокусе находится панель управления WordPress, запрос Heartbeat должен быть разнесен не более чем на 60 секунд, что позволяет API. Если приборная панель не в фокусе, Heartbeat запрашивает интервал до 120 секунд между ними.

00:29:30 «GET /wp-admin/index.php «https://example.com/wp-admin/index.php»
00:30:31 «POST /wp-admin/admin-ajax.php «https://example.com/wp-admin/index.php»
00:32:03 «POST /wp-admin/admin- ajax.php "https://example.com/wp-admin/index.php"
00:33:03 "POST /wp-admin/admin-ajax.php" https://example.com/wp-admin /index.php"
00:34:03 "POST /wp-admin/admin-ajax.php" https://example.com/wp-admin/index.php"
00:35:04 "POST /wp -admin/admin-ajax.php «https://example.com/wp-admin/index.php»
00:36:04 «POST /wp-admin/admin-ajax.php» «https://example. com/wp-admin/index.php»
00:37:04 «POST /wp-admin/admin-ajax.php» https://example.com/wp-admin/index.php»
00:38:04 «POST /wp-admin/admin- ajax.php "https://example.com/wp-admin/index.php"
00:39:04 "POST /wp-admin/admin-ajax.php" https://example.com/wp-admin /index.php"
00:40:04 "POST /wp-admin/admin-ajax.php" https://example.com/wp-admin/index.php"
00:42:04 "POST /wp -admin/admin-ajax. php «https://example.com/wp-admin/index.php»
00:44:04 «POST /wp-admin/admin-ajax.php» «https://example. com/wp-admin/index.php»
00:46:04 "POST /wp-admin/admin-ajax.php" https://example.com/wp-admin/index.php"
00:47:04 "POST /wp-admin/admin- ajax.php "https://example.com/wp-admin/index.php"
00:48:04 "POST /wp-admin/admin-ajax.php" https://example.com/wp-admin /index.php»
00:49:04 «POST /wp-admin/admin-ajax.php» https://example.com/wp-admin/index.php»
00:50:04 «POST /wp -admin/admin-ajax.php «https://example.com/wp-admin/index.php»
00:51:04 «POST /wp-admin/admin-ajax.php» «https://example. com/wp-admin/index.php»
00:53:04 «POST /wp-admin/admin-ajax.php» https://example.com/wp-admin/index.php»
00:55:08 «POST /wp-admin/admin- ajax.php "https://example.com/wp-admin/index.php"
00:57:04 "POST /wp-admin/admin-ajax.php" https://example.com/wp-admin /index.php"
00:59:04 "POST /wp-admin/admin-ajax.php" https://example.com/wp-admin/index. php"
01:01:05 "POST /wp -admin/admin-ajax.php «https://example.com/wp-admin/index.php»
01:03:05 «POST /wp-admin/admin-ajax.php» «https://example. com/wp-admin/index.php»

Теперь для каждого из этих POST-запросов выполнялся соответствующий PHP-скрипт на сервере с использованием процессорного времени:

php-cgi 0,26 сек. 0,23 с Ср 19 фев 00:32
php-cgi 0,20 с Ср 19 фев 00:33
php-cgi 0,22 с Ср 19 фев 00:34
php-cgi 0,24 с Ср 19 фев 00:35
php-0 с 0,22 с Ср 19 фев 00:36
php-cgi 0,23 сек Ср 19 фев 00:37
php-cgi 0,23 сек Ср 19 фев 00:38
php-cgi 0,26 сек Ср 19 фев00:39
php-cgi 0,22 сек. 46
php-cgi 0,25 сек. php-cgi 0,21 сек. cgi 0,25 сек., среда, 19 фев.00:59
php-cgi 0,22 секунды Среда, 19 февраля 01:01
php-cgi 0,23 секунды Среда, 19 февраля 01:03

При открытии нашей информационной панели более получаса было сгенерировано 25 выполнений PHP-скриптов. При общем использовании 5,77 секунд ЦП. Не ужасно, но и не здорово, так как мы израсходовали ЦП, по сути, проверяя, чтобы ничего не произошло.

Отключить WordPress Heartbeat API

Если вы заметили, что у вас слишком много запросов admin-ajax.php , WordPress Heartbeat API можно отключить, чтобы этот тип активности не выполнялся автоматически.

ПРИМЕЧАНИЕ. По умолчанию WordPress использует Heartbeat API для управления такими вещами, как блокировка сообщений, поэтому только один администратор может одновременно редактировать сообщение. Он также используется для автоматического сохранения. В дальнейшем разработчики WordPress могут все больше и больше использовать API для решения определенных задач, поэтому имейте это в виду, если решите отключить его.

Инструкции по использованию последней версии Heartbeat Control можно найти в нашем новом руководстве, нажав здесь.

Установка плагина Heartbeat Control

1. Сначала войдите в панель администратора WordPress.
2. На панели инструментов наведите указатель мыши на Плагины и нажмите Добавить новый .
3. На этой странице введите Heartbeat Control в поле поиска вверху и нажмите клавишу Enter на клавиатуре, чтобы выполнить поиск.
4. Поскольку вы искали точное название подключаемого модуля, оно должно быть первым из результатов. Чтобы установить его, нажмите на кнопку Install Now 9.кнопка 0102.
5. Теперь WordPress будет обрабатывать загрузку и установку плагина Heartbeat Control. Конечно, не забудьте нажать Activate Plugin , когда закончите.

Настройка плагина Heartbeat Control

1. Теперь, когда у вас установлен плагин Heartbeat Control, вам нужно настроить его параметры. Чтобы получить доступ к странице настроек, наведите указатель мыши на Инструменты  в левой панели меню и нажмите «Управление сердцебиением».
   
2. Оказавшись на странице настроек, вы увидите 2 разных выпадающих списка. Первое поле позволит вам отключить сердцебиение WordPress на всем сайте или в определенных местах. В зависимости от ваших потребностей, вы можете полностью отключить пульс WordPress или разрешить его только в определенных местах, например, на странице редактирования публикации.
   
3. Второе поле позволяет вам определить, как часто API сердцебиения WordPress будет делать запрос. Например, на страницах редактирования сообщений он делает запрос POST каждые 15 секунд. Это можно изменить в  частота сердцебиения  раскрывающееся меню для задержки до 60 секунд между запросами, что сократит ресурсы сервера, вызванные запросами admin-ajax, на 75%.
   
4. После внесения изменений нажмите Сохранить изменения .

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