Ajax в wordpress

Содержание

Когда admin-ajax.php действительно является проблемой

Рассмотрим несколько вариантов, когда admin-ajax.php действительно становится источником высокой нагрузки на ваш сервер, и как бороться с этой нагрузкой.


Запросы на admin-ajax.php занимают более 1 секунды

В среднем запросы на admin-ajax.php могут занимать около 300 мс. Если же на вашем сайте данные запросы выполняются более чем за одну секунду, то необходимо разобраться. Используйте средства профилирования, чтобы понять чем именно занят процесс все это время. Наверняка вы найдете медленную функцию в вашей теме или плагине, которая не имеет никакого отношения к AJAX запросам.

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

Бывает и такое, что запросы на admin-ajax.php становятся медленными не из-за конкретных плагинов или тем, а из-за неоптимальной конфигурации сервера MySQL. Такое бывает достаточно редко, и в этом случае следует заняться оптимизацией сервера базы данных.

Подозрительное содержание запроса

Файл admin-ajax.php (и admin-post.php) часто выбирается злоумышленниками для того, чтобы использовать известную уязвимость в каком-нибудь плагине. В качестве примера можно привести недавний инцидент с популярным плагином FancyBox, где именно admin-ajax.php (или admin-post.php) послужил точкой входа.

Эти файлы выбираются не спроста, ведь каждый из них исполняет событие даже для анонимных HTTP запросов. Многие разработчики плагинов и тем, ошибочно считают, что раз выполняется событие , значит пользователь выполнил вход и имеет права администратора. Это не так. Повторяем — событие выполняется даже для анонимных HTTP запросов.

Итак, в случае с уязвимостью плагина FancyBox for WordPress, вот примерно то, как выглядит «подозрительное содержание запроса»:

46.4.76.174 – – [04/Feb/2015:00:25:09 -0500] "POST /wp-admin/admin-ajax.php?page=fancybox-for-wordpress HTTP/1.1" 403 4207 INPUTBODY:action=update&mfbfw%5Bext...

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

Неузнаваемые IP адреса

Этот пункт тесно связан с предыдущим. Если вы увидели запросы на admin-ajax.php с неузнаваемых IP адресов, то необходимо проанализировать эти запросы, и понять чего именно пытается сделать злоумышленник. IP адреса можно заблокировать, например по шаблону с помощью fail2ban.

Слишком частая периодичность запросов

Как мы уже упомянули, на активной вкладке при редактировании записи, WordPress выполняет AJAX запрос каждые 15 секунд, т.е. для достижения 1 запроса в секунду на сервере, вам необходимо 15 редакторов с открытой вкладкой. Если вы являетесь единственным редакторов на вашем сайте, а запросов на admin-ajax.php с вашего IP адреса более 1 в секунду (мы встречали и 20/с), то стоит с этим разобраться.

Самой частой причиной подобного поведения является тема или плагин, поэтому следует их деактивировать и включать по порядку, чтобы найти источник. Здесь стоит также упомянуть плагин Heartbeat Control, который позволяет изменять стандартную конфигурацию Heartbeat в WordPress, но учтите, что отключив Heartbeat вы скорее временно скрываете проблему, а не устраняете ее.

Отлавливаем баги, PHP ошибки

Проблемы могут возникнуть при AJAX запросе и появлении ошибок PHP. Заметки или сообщения могут изменить возвращаемый результат или вызвать ошибку javascript.

Дебаг (вывод ошибок на экран)

Вариант:

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

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

Вариант: включаем показ ошибок в AJAX запросах

WordPress по умолчанию не показывает ошибки для AJAX запросов даже если константа WP_DEBUG включена! Видно это в коде функции wp_debug_mode().

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

Чтобы включить показ ошибок при AJAX запроса, нужно вставить такой код в файл темы или в плагин. Но лучшее его вставить как можно раньше, чтобы видеть ранние ошибки, лучше всего в MU плагины…

if( WP_DEBUG && WP_DEBUG_DISPLAY && (defined('DOING_AJAX') && DOING_AJAX) ){
	@ ini_set( 'display_errors', 1 );
}

Вариант: вывод данных в лог файл

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

error_log( print_r($myvar, true) );

В результате, в файл логов сервера (error.log) будет записано содержимое переменной . Так можно выполнить ajax, и заглянуть в лог.

Вариант: вывод PHP ошибок в лог файл

Чтобы выводить PHP заметки и ошибки в лог файл, нужно включить константу WP_DEBUG_LOG. Такой лог файл появится в папке wp-content.

Вариант:


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

ob_clean();
echo $whatever;
die();

После этого нужно посмотреть что возвращает запрос через дебаг браузера или как-то еще…

Вариант:

Ошибка при возвращении данных

Если AJAX запрос на в файл wp-admin/admin-ajax.php провалился, то будет возвращен ответ -1 или .

  • -1 — ошибка при проверке запроса. См. функцию check_ajax_referer()
  • — обработка запроса вернула пустой результат
  • — также возвращается по умолчанию во всех остальных случаях.

Дополнения от Google 2019 года

  • Термин «запись» заменяется на общий термин «строка» или «правило».
  • Google устанавливает максимальный размер файла robots.txt в 500 кибибайт (КиБ). Контент сверх этого лимита игнорируется. 1 кибибайт равен 1024 байта.
  • Поисковик не обрабатывает элементы с простыми ошибками или опечатками.
  • Роботы Гугл делают минимум 5 переходов в цепочке переадресаций, если файл robots.txt не удается получить сразу. Если в результате файл robots.txt не обнаруживается, роботы Google интерпретируют это как ошибку 404.
  • Файл robots.txt должен располагаться в каталоге верхнего уровня хоста и быть доступным при использовании нужного протокола и номера порта. Google поддерживает все протоколы в том числе HTTP и HTTPS.
  • URL файла robots.txt чувствителен к регистру.
  • Формальный синтаксис файла robots.txt соответствует дополненной форме Бэкуса – Наура (ABNF) и включает  символы UTF-8.
  • Файл должен содержать обычный текст в кодировке UTF-8 и состоять из строк, разделённых символами CR, CR/LF или LF.
  • Каждая действительная строка состоит из поля, двоеточия и значения. Использовать пробелы НЕ обязательно, но рекомендуется для удобства чтения.
  • Комментарии можно размещать в любом месте файла, закрывая их символом #(решётка). После этого символа  до конца строки контент расценивается как комментарий и игнорируется.

Для чего нужен этот файл

А вот для чего:

  • запрета на индексацию мусора — страниц и разделов, которые не содержат в себе полезный контент;
  • разрешение индексации нужных страниц и разделов;
  • чтобы давать разные задачи роботам разных поисковиков — то есть, например, Яндексу разрешить индексировать всё, а Рамблеру — ничего;
  • можно также задавать роботам разные категории. Заморочиться например вплоть до того, что Гуглу разрешить индексировать только картинки, а Яху — только карту сайта;
  • чтобы показать через директиву Host Яндексу, какое у сайта главное зеркало;
  • еще некоторые вебмастера запрещают всяким нехорошим парсерам сканировать сайт с помощью этого файла;

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

Динамический robots.txt

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

О том как работает динамическое создание файла читайте в описании функции do_robots(), а ниже я приведу пример как можно изменить содержание этого файла, налету, через хук do_robotstxt.

Для этого добавьте следующий код в файл :

add_action( 'do_robotstxt', 'my_robotstxt' );
function my_robotstxt(){

	$lines = [
		'User-agent: *',
		'Disallow: /wp-admin/',
		'Disallow: /wp-includes/',
		'',
	];

	echo implode( "\r\n", $lines );

	die; // обрываем работу PHP
}
User-agent: *
Disallow: /wp-admin/
Disallow: /wp-includes/

Problems That admin-ajax.php Can Cause

Overflowing the admin-ajax.php file can cause a page load time issue, which is a serious problem. The internet golden rule is that your site should fully load within 3 seconds or less. If it takes longer than that, chances are you give visitors a bad experience and drive them away.

Slow page speed can negatively affect your SEO ranking too. You should be aware that Google uses load speed as one of the indicators in their algorithm to rank sites. Besides, slow page speed means that the search engine can crawl fewer pages using their allocated crawl budget, and that will affect your pages indexation even further.

For some of us, the only time we’re dealing with this API is when we use speed test tools — such as GTmetrix, to figure out why admin-ajax.php is slowing down our websites.

The causes for spikes can be from two different sources, either caused by third-party plugins or WordPress Heartbeat API request on the admin section. We’ll discuss it in more detail below.

How Plugins Can Overflow the admin-ajax.php File

Third-party plugins cause the most common problem when users see a spike on admin-ajax.php. If done correctly, AJAX is definitely a good thing, as developers usually use it to add functionality to their plugins. For example, developers can use AJAX requests and create a custom wp_query to display dynamic content on a cached page.

But sometimes when many plugins use these queries, they can cause an overflow. Thus it can create a spike and slow down the whole website. So, if you’re a developer, here’s a resource to properly implement AJAX in plugins.

As a website owner, you may need to diagnose the plugins first before disabling them. This is important to figure out if a particular plugin causes the load time issue.

AJAX во внешней части WordPress

Первое в чем нужно убедиться — установлена ли на сайте библиотека jQuery.

Во фронт-энде (внешней части сайта) нужно использовать еще один хук для обработки AJAX запросов: . Этот хук в отличии от , срабатывает для неавторизованных пользователей.

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

add_action('wp_ajax_(action)', 'my_action_callback');
add_action('wp_ajax_nopriv_(action)', 'my_action_callback');

‘wp_ajax_nopriv_(action)’ можно не указывать, если не нужно, чтобы AJAX запрос обрабатывался для неавторизованных пользователей.

Переменная 

Напомню, что переменная ajaxurl есть только в админке и её нет в лицевой части сайта (фронт-энде), поэтому её нужно определить (создать). Но мы назовем её по-другому — myajax.url, для фронта так удобнее, потому что так в объект myajax можно будет добавить еще данные связанные с AJAX запросом.

Правильный способ создать такую переменную — это использовать функцию wp_localize_script().

// Подключаем локализацию в самом конце подключаемых к выводу скриптов, чтобы скрипт
// 'twentyfifteen-script', к которому мы подключаемся, точно был добавлен в очередь на вывод.
// Заметка: код можно вставить в любое место functions.php темы
add_action( 'wp_enqueue_scripts', 'myajax_data', 99 );
function myajax_data(){

	// Первый параметр 'twentyfifteen-script' означает, что код будет прикреплен к скрипту с ID 'twentyfifteen-script'
	// 'twentyfifteen-script' должен быть добавлен в очередь на вывод, иначе WP не поймет куда вставлять код локализации
	// Заметка: обычно этот код нужно добавлять в functions.php в том месте где подключаются скрипты, после указанного скрипта
	wp_localize_script( 'twentyfifteen-script', 'myajax', 
		array(
			'url' => admin_url('admin-ajax.php')
		)
	);  

}

В результате, получим в head части сайта прямо перед скриптом ‘twentyfifteen-script’:

<script type='text/javascript'>
/* <![CDATA[ */
var myajax = {"url":"http://wptest.ru/wp-admin/admin-ajax.php"};
/* ]]> */
</script>
<script type='text/javascript' src='http://wptest.ru/wp-content/themes/twentyfifteen/js/functions.js?ver=20150330'></script>

На этом теория AJAX закончена, теперь все как для админ части, только вместо ajaxurl указываем myajax.url и нужно прикрепить функцию обработчик на еще один хук wp_ajax_nopriv_(action).

Пример AJAX кода для фронт энда

<?php

add_action( 'wp_enqueue_scripts', 'myajax_data', 99 );
function myajax_data(){

	wp_localize_script('twentyfifteen-script', 'myajax', 
		array(
			'url' => admin_url('admin-ajax.php')
		)
	);  

}

add_action('wp_footer', 'my_action_javascript', 99); // для фронта
function my_action_javascript() {
	?>
	<script type="text/javascript" >
	jQuery(document).ready(function($) {
		var data = {
			action: 'my_action',
			whatever: 1234
		};

		// 'ajaxurl' не определена во фронте, поэтому мы добавили её аналог с помощью wp_localize_script()
		jQuery.post( myajax.url, data, function(response) {
			alert('Получено с сервера: ' + response);
		});
	});
	</script>
	<?php
}

add_action('wp_ajax_my_action', 'my_action_callback');
add_action('wp_ajax_nopriv_my_action', 'my_action_callback');
function my_action_callback() {
	$whatever = intval( $_POST );

	echo $whatever + 10;

	// выход нужен для того, чтобы в ответе не было ничего лишнего, только то что возвращает функция
	wp_die();
}

Код рассчитан на тему twentyfifteen. Вставлять код можно в functions.php темы.

Этот код будет работать для любой темы, единственное что для этого нужно — это поменять название основного скрипта темы twentyfifteen-script, который подключается после jquery.

New Feature Explanations

1. Spinning Integration


Rewriter integration saw the biggest changes. All rewritings settings were moved from the «Options» page to the «All Rewriters» page, which is basically a separate plugin we have built and integrated into WP Robot for better rewriter integration, easier updating and more features. You can even download All Rewriters as a stand-alone version too.

These are the advantages and changes of the new system:

  • A new Instant Spinning metabox on the WordPress «Add New» editor screens. It allows you to use any rewriters you have set up on the article you are working on, compare the results and instantly apply it if satisfactory. Go here to see a few images of the new section.

2. Intelligent Keyword Replace

You can find this useful new setting on the WP Robot «Options» page. What it does can be a little bit hard to understand, which is why it is best explained with an example:

Let’s assume you have a WP Robot post template in your campaign containing 3 modules: Amazon, Youtube and then Yahoo Answers (so it would look like this: {amazon} {youtube} {yahooanswers} ). By default your campaign would contain a keyword that is used to search all 3 of those modules for content. With «Intelligent Keyword Replace» active the keyword is only used to search the first module, in this case Amazon, for content. For the other modules WP Robot then uses the title returned by the 1st module as keyword. Say if the keyword was «Apple iphone» and Amazon returns the «Apple iPhone 4 16GB (Black)» product, then this is the keyword for Youtube and Yahoo Answers. The advantage: Your modules will have more relevant and matching content. You will have a Youtube video fitting the «Apple iPhone 4 16GB (Black)» Amazon product and not one for maybe another iphone model.

To sum up:

  • Intelligent Keyword Replace uses the title of the 1st module in your post template as the keyword for all following modules.
  • That means it only has an effect if you use more than 1 module in a template.
  • The result will be more targeted content for the following modules. However it can also lead to no content being found if the title is too specific, which is why you should use the setting with caution.

3. Improved Image Caching

This update improves the «Save Images to Server» setting on the Options page, which is now set to «on» by default on new blogs and can now save all images in posts WP Robot creates to your server automatically with much more efficiency. The biggest advantage of this change is with the RSS Module. Earlier if a RSS feed in WP Robot contained images as part of the feed content they could not be saved to your server. Now in WP Robot 4 all images in an RSS feed will be downloaded and saved locally as well as a featured image will be set.

4. Disable Modules

You can find the new disable module settings by going to the «Options» page and clicking the disable modules tab at the top. Here you can deselect any modules you do not intend to use on the current blog. After saving the selection those modules are hidden from the Options page, the Templates page and the Create Campaigns screen. You can reenable them at any time.

We hope you enjoy the latest version and as always feedback as well as reports of any problems are welcome.

Order WP Robot Risk Free Now:

Buy the Full Version (best value)

The full version of WP Robot 4 includes all 24 modules, can post content from 23 different sources and lets you earn commission from 9 affiliate networks! You may use the plugin on all your websites!

→ Order Now!

Buy a Custom Version

Build yourself a custom version of WP Robot 4 and select only the modules and features you need! Order 3 or more modules to get a rebate and free bonuses!

→ Build Now!

Your Advantages:

  • Plugin will be delivered to you instantly after payment has been made!
  • You have a 14 day money-back guarantee in case you are not satisfied — no questions asked!
  • Free support via the WP Robot support forum and free updates included with every order!

Включаем кэширование для AJAX запросов

По умолчанию все AJAX запросы НЕ кэшируются браузером для этого PHP устанавливает специальные заголовки функцией nocache_headers().

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

Как включить кэширование для указанных AJAX запросов смотрите во втором примере функции nocache_headers().

Diagnosing Plugins

Conflicting plugins can cause a load time issue. The old school way is you can always disable all plugins to fix the problem, and re-enable them one by one using a process of elimination. But it’s definitely not a great solution.

We’ll use a more proper method to figure out the root cause of the problem with the following scenario.

Upon activating several plugins, you notice that your website needs a longer time to fully load. You then diagnose the site using GTmetrix. It’s a powerful free speed test tool that allows us to see the individual post response data.

Method A

Go to GTmetrix homepage, fill out your website URL, and click Analyze. It takes a while to analyze your site completely.

The Waterfall window will present all of your website’s elements. While the rest of the files look ok, you notice that POST admin-ajax.php takes a longer loading time.

Click on POST admin-ajax.php, and you’ll see four different tabs available: Headers, Parameters, Post, and Response. When diagnosing this kind of issue, the Post and Response tabs are the place you need to look at.

For this site, we see a clue in the Post tab as that request has something to do with the “count_hit” script.

That clue is leading us to suspect a certain post hit counter plugin that we’ve installed earlier. So, to prove that theory, we disable that plugin and run a second test with GTmetrix for our site.

Method B

You can also use the Chrome developer console to find the suspected plugin.

Open your website. Right-click in the page -> Inspect. Alternatively, on the Chrome tab go to View -> Developer -> Developer Tools.

Click on Network tab and reload your website.

In the filter box (right below the red dot) enter admin-ajax.php. You’ll see the culprit for the said issue. After that, you can disable the plugin and test if the problem still exists.

As a website owner, if you really need to use this plugin, make sure to use the most updated version. If you’ve done that and the problem persists, reach out the plugin developer while mentioning this case.


If the developer cannot resolve the issue yet, you can always replace it with a new one. The beauty of WordPress is there are many similar plugins to choose from. Just go to the WordPress plugins directory and select the most used and updated plugin that offers the same functionality.

Вариант 1: оптимальный код robots.txt для WordPress

User-agent: *
Disallow: /cgi-bin          # классика...
Disallow: /?                # все параметры запроса на главной
Disallow: /wp-              # все файлы WP: /wp-json/, /wp-includes, /wp-content/plugins
Disallow: *?s=              # поиск
Disallow: *&s=              # поиск
Disallow: /search           # поиск
Disallow: /author/          # архив автора
Disallow: */embed           # все встраивания
Disallow: */page/           # все виды пагинации
Allow: */uploads            # открываем uploads
Allow: /*/*.js              # внутри /wp- (/*/ - для приоритета)
Allow: /*/*.css             # внутри /wp- (/*/ - для приоритета)
Allow: /wp-*.png            # картинки в плагинах, cache папке и т.д.
Allow: /wp-*.jpg            # картинки в плагинах, cache папке и т.д.
Allow: /wp-*.jpeg           # картинки в плагинах, cache папке и т.д.
Allow: /wp-*.gif            # картинки в плагинах, cache папке и т.д.
Allow: /wp-*.svg            # картинки в плагинах, cache папке и т.д.
Allow: /wp-*.pdf            # файлы в плагинах, cache папке и т.д.
Allow: /wp-admin/admin-ajax.php
#Disallow: /wp/             # когда WP установлен в подкаталог wp

Sitemap: http://example.com/sitemap.xml     
Sitemap: http://example.com/sitemap2.xml    # еще один файл
#Sitemap: http://example.com/sitemap.xml.gz # сжатая версия (.gz)

# Версия кода: 1.1
# Не забудьте поменять `site.ru` на ваш сайт.

Разбор кода:

  1. В строке User-agent: * мы указываем, что все нижеприведенные правила будут работать для всех поисковых роботов *. Если нужно, чтобы эти правила работали только для одного, конкретного робота, то вместо * указываем имя робота (User-agent: Yandex, User-agent: Googlebot).

  2. В строке Allow: */uploads мы намеренно разрешаем индексировать страницы, в которых встречается /uploads. Это правило обязательно, т.к. выше мы запрещаем индексировать страницы начинающихся с /wp-, а /wp- входит в /wp-content/uploads. Поэтому, чтобы перебить правило Disallow: /wp- нужна строчка Allow: */uploads, ведь по ссылкам типа /wp-content/uploads/… у нас могут лежать картинки, которые должны индексироваться, так же там могут лежать какие-то загруженные файлы, которые незачем скрывать. Allow: может быть «до» или «после» Disallow:.

  3. Остальные строчки запрещают роботам «ходить» по ссылкам, которые начинаются с:

    • Disallow: /cgi-bin — закрывает каталог скриптов на сервере
    • Disallow: ?s= или Disallow: *?s= — закрыавет страницы поиска
    • Disallow: */page/ — закрывает все виды пагинации
  4. Правило Sitemap: http://example.com/sitemap.xml указывает роботу на файл с картой сайта в формате XML. Если у вас на сайте есть такой файл, то пропишите полный путь к нему. Таких файлов может быть несколько, тогда указываем путь к каждому отдельно.

  5. В строке Host: site.ru мы указываем главное зеркало сайта. Если у сайта существуют зеркала (копии сайта на других доменах), то чтобы Яндекс индексировал всех их одинаково, нужно указывать главное зеркало. Директива Host: понимает только Яндекс, Google не понимает! Если сайт работает под https протоколом, то его обязательно нужно указать в Host: Host: http://example.com

    Из документации Яндекса: «Host — независимая директива и работает в любом месте файла (межсекционная)». Поэтому её ставим наверх или в самый конец файла, через пустую строку.

Не рекомендуется исключать фиды: Disallow: */feed

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

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

Директива Host для Яндекса больше не нужна

Яндекс полностью отказывается от директивы Host, её заменил 301 редирект. Host можно смело удалять из

Однако важно, чтобы на всех зеркалах сайта стоял 301 редирект на главный сайт (главное зеркало)

Yandex и Google обрабатывает директивы Allow и Disallow не по порядку в котором они указаны, а сначала сортирует их от короткого правила к длинному, а затем обрабатывает последнее подходящее правило:

User-agent: *
Allow: */uploads
Disallow: /wp-

будет прочитана как:

User-agent: *
Disallow: /wp-
Allow: */uploads

Таким образом, если проверяется ссылка вида: /wp-content/uploads/file.jpg, правило Disallow: /wp- ссылку запретит, а следующее правило Allow: */uploads её разрешит и ссылка будет доступна для сканирования.

Чтобы быстро понять и применять особенность сортировки, запомните такое правило: «чем длиннее правило в robots.txt, тем больший приоритет оно имеет. Если длина правил одинаковая, то приоритет отдается директиве Allow.»

О файле robots.txt

Файл robots.txt это текстовой файл, в котором прописываются правила для поисковых машин для сканирования, а значит индексации папок и файлов сайта. Находится файл robots.txt должен в корневом каталоге сайта. Файл robots.txt наряду с картой сайта Sitemap  это основные документы SEO оптимизации блогов сделанных на CMS WordPress.

Важно! Недопустимо пустые переводы строк между директивами и (), а также между директивами и. Важно! URL файла robots.txt чувствителен к регистру

Важно! URL файла robots.txt чувствителен к регистру. На базовой версии файл robots.txt для wordpress выглядит следующим образом:

На базовой версии файл robots.txt для wordpress выглядит следующим образом:

  • User-agent это обращение к поисковикам. звезда, означает, что следующие директивы группы обращены ко всем поисковикам;
  • Директива Disallow запрещает поисковикам индексировать только то, что находится в папках /wp-admin/ и /wp-includes/.

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

Директива Clean-param

Если адреса страниц сайта содержат динамические параметры, которые не влияют на их содержимое (идентификаторы сессий, пользователей, рефереров и т. п.), вы можете описать их с помощью директивы Clean-param.

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

Например, на сайте есть страницы:

Параметр ref используется только для того, чтобы отследить с какого ресурса был сделан запрос и не меняет содержимое, по всем трем адресам будет показана одна и та же страница с книгой book_id=123. Тогда, если указать директиву следующим образом:

робот Яндекса сведет все адреса страницы к одному:

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

Синтаксис директивы

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

Примечание. Директива Clean-Param является межсекционной, поэтому может быть указана в любом месте файла robots.txt. В случае, если директив указано несколько, все они будут учтены роботом.

Префикс может содержать регулярное выражение в формате, аналогичном файлу robots.txt, но с некоторыми ограничениями: можно использовать только символы A-Za-z0-9.-/*_. При этом символ * трактуется так же, как в файле robots.txt: в конец префикса всегда неявно дописывается символ *. Например:

означает, что параметр s будет считаться незначащим для всех URL, которые начинаются с /forum/showthread.php. Второе поле указывать необязательно, в этом случае правило будет применяться для всех страниц сайта.

Регистр учитывается. Действует ограничение на длину правила — 500 символов. Например:

Вариант 2: стандартный robots.txt для WordPress

Не знаю кто как, а я за первый вариант! Потому что он логичнее — не надо полностью дублировать секцию ради того, чтобы указать директиву Host для Яндекса, которая является межсекционной (понимается роботом в любом месте шаблона, без указания к какому роботу она относится). Что касается нестандартной директивы Allow, то она работает для Яндекса и Гугла и если она не откроет папку uploads для других роботов, которые её не понимают, то в 99% ничего опасного это за собой не повлечет. Я пока не заметил что первый robots работает не так как нужно.

  1. Некоторые роботы (не Яндекса и Гугла) — не понимают более 2 директив: User-agent: и Disallow:

3. Sitemap: межсекционная директива для Яндекса и Google и видимо для многих других роботов тоже, поэтому её пишем в конце через пустую строку и она будет работать для всех роботов сразу.

На основе этих поправок, корректный код должен выглядеть так:

User-agent: Yandex
Disallow: /wp-admin
Disallow: /wp-includes
Disallow: /wp-content/plugins
Disallow: /wp-json/
Disallow: /wp-login.php
Disallow: /wp-register.php
Disallow: */embed
Disallow: */page/
Disallow: /cgi-bin
Disallow: *?s=
Allow: /wp-admin/admin-ajax.php

Host: site.ru

User-agent: *
Disallow: /wp-admin
Disallow: /wp-includes
Disallow: /wp-content/plugins
Disallow: /wp-json/
Disallow: /wp-login.php
Disallow: /wp-register.php
Disallow: */embed
Disallow: */page/
Disallow: /cgi-bin
Disallow: *?s=
Allow: /wp-admin/admin-ajax.php

Sitemap: http://example.com/sitemap.xml

Заключение

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

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

Ходят слухи, что Google иногда может проигнорировать правила в и взять страницу в индекс, если сочтет, что страница ну очень уникальная и полезная и она просто обязана быть в индексе. Однако другие слухи опровергают эту гипотезу тем, что неопытные оптимизаторы могут неправильно указать правила в и так закрыть нужные страницы от индексации и оставить ненужные. Я больше склоняюсь ко второму предположению…


С этим читают