Налаштовуємо файл robots.txt для WordPress

У цій статті є приклад оптимального, на мій погляд, коду для файлу robots.txt під WordPress, який ви можете використовувати у своїх сайтах.

Для початку, пригадаємо навіщо потрібний robots.txt — файл robots.txt потрібен виключно для пошукових роботів, щоб «сказати» їм, які розділи/сторінки сайту відвідувати, а які відвідувати не потрібно. Сторінки, які закриті від відвідування не потраплятимуть до індексу пошукових систем (Yandex, Google тощо).

Закрити сторінку від робота можна також через мета-тег robots або в заголовку HTTP відповідіX-Robots-Tag . Перевага файлу robots.txt в тому, що робот при відвідуванні сайту спочатку завантажує всі правила з файлу robots.txt і спираючись на них ходить по сторінках сайту, крім відвідування сторінки, URL яких не підходить під правила.

Таким чином, якщо ми закрили сторінку в robots.txt, робот просто пропустить її, не зробивши жодних запитів на сервер. А якщо ми закрили сторінку в заголовку X-Robots-Tagабо мета-тезі, роботу потрібно спочатку зробити запит до сервера, отримати відповідь, подивитися, що знаходиться в заголовку або метатезі і тільки потім ухвалити рішення індексувати сторінку чи ні.

Таким чином, файл robots.txt пояснює роботу яких сторінок (URL) сайту потрібно просто пропускати не роблячи жодних запитів. Це заощаджує час обходу роботом всіх сторінок сайту та заощаджує ресурси сервера.

Розглянемо з прикладу. Допустимо, у нас є сайт на якому всього 10 000 сторінок (не 404 URL). З них корисних сторінок з унікальним контентом всього 3000 , решта це архіви за датами, авторами, сторінки пагінації та інші сторінки контент на яких дублюється (наприклад, фільтри з GET параметрами). Допустимо, ми хочемо закрити від індексації ці 7000 неунікальних сторінок:

1. якщо зробити це через robots.txt , то роботу для індексації всього сайту потрібно буде відвідати всього 3000 сторінок, решта буде відсіяно відразу ж на рівні URL.
2. якщо зробити це через мета-тег robots , то роботу для індексації всього сайту потрібно буде відвідати всі 10 000 сторінок сайту. Тому що потрібно отримати контент сторінки, щоб дізнатися, що знаходиться в мета-тезі (у якому зазначено, що сторінку індексувати не потрібно).

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

Оптимальний код robots.txt для WordPress

Важливо розуміти, що наведено нижче універсальний приклад коду для файлу robots.txt . Для кожного конкретного сайту його потрібно розширювати чи вносити коригування. І краще не чіпайте нічого якщо не розумієте, що робите – звертайтеся до знаючих людей.

Версія 1 (не строга)

Ця версія, мабуть, краща в порівнянні з другою, тому що тут немає небезпеки заборонити індексацію будь-яких файлів всередині ядра WordPress або папки wp-content.

User-agent: * # Створюємо секцію правил для роботів. * значить для всіх
								роботів. Щоб вказати секцію правил для окремого
								робота, замість * вкажіть його ім'я: GoogleBot, Yandex.
Disallow: /cgi-bin # Стандартна папка на хостингу.
Disallow: /wp-admin/ # Закриваємо адмінку.
Allow: /wp-admin/admin-ajax.php # Відкриємо аякс.
Disallow: /? # Усі параметри запиту на головній.
Disallow: *?s= # Пошук.
Disallow: *&s= # Пошук.
Disallow: /search # Пошук.
Disallow: /author/ # Архів автора.
Disallow: */embed$ # Усі вбудовування.
Disallow: */xmlrpc.php # Файл WordPress API
Disallow: *utm*= # Посилання з utm-мітками
Disallow: *openstat= # Посилання з мітками openstat

# Одна чи кілька посилань на карту сайту (файл Sitemap). Це незалежна
директива і дублювати її для кожного User-agent не потрібно. Так наприклад
# Google XML Sitemap створює 2 карти сайту:
Sitemap: http://example.com/sitemap.xml
Sitemap: http://example.com/sitemap.xml.gz

# Версія коду: 2.0
# Не забудьте змінити 'example.com' на ваш сайт.

Версія 2 (сувора)

У цьому варіанті ми контролюємо всі доступи. Спочатку глобально забороняємо доступ до майже всього від WP ( Disallow: /wp-), а потім відкриваємо там де потрібно.

User-agent: * # Створюємо секцію правил для роботів. * значить для всіх
							   роботів. Щоб вказати секцію правил для окремого
							   робота, замість * вкажіть його ім'я: GoogleBot, Yandex.
Disallow: /cgi-bin # Стандартна папка на хостингу.
Disallow: /wp- # Все пов'язане з WP - це: /wp-content /wp-admin
							   # /wp-includes /wp-json wp-login.php wp-register.php.
Disallow: /wp/ # Каталог куди встановлено ядро ​​WP (якщо ядро ​​встановлено
							   # у підкаталог). Якщо WP встановлено стандартно, то
							   правило можна видалити.
Disallow: /? # Усі параметри запиту на головній.
Disallow: *?s= # Пошук.
Disallow: *&s= # Пошук.
Disallow: /search # Пошук.
Disallow: /author/ # Архів автора.
Disallow: */embed$ # Усі вбудовування.
Disallow: */xmlrpc.php # Файл WordPress API
Disallow: *utm*= # Посилання з utm-мітками
Disallow: *openstat= # Посилання з мітками openstat
Allow: */wp-*/*ajax*.php # AJAX запити: */admin-ajax.php */front-ajaxs.php
Allow: */wp-sitemap # карта сайту (головна та вкладені)
Allow: */uploads # відкриваємо uploads
Allow: */wp-*/*.js # всередині /wp- (/*/ - для пріоритету)
Allow: */wp-*/*.css # всередині /wp- (/*/ - для пріоритету)
Allow: */wp-*/*.png # картинки в плагінах, cache папці і т.д.
Allow: */wp-*/*.jpg # картинки в плагінах, cache папці і т.д.
Allow: */wp-*/*.jpeg # картинки в плагінах, cache папці і т.д.
Allow: */wp-*/*.gif # картинки в плагінах, cache папці і т.д.
Allow: */wp-*/*.svg # картинки в плагінах, cache папці і т.д.
Allow: */wp-*/*.webp # файли в плагінах, cache папці і т.д.
Allow: */wp-*/*.swf # файли в плагінах, cache папці і т.д.
Allow: */wp-*/*.pdf # файли в плагінах, cache папці і т.д.
							   # Секція правил закінчена

# Одна чи кілька посилань на карту сайту (файл Sitemap). Це незалежна
директива і дублювати її для кожного User-agent не потрібно. Так наприклад
# Google XML Sitemap створює 2 карти сайту:
Sitemap: http://example.com/wp-sitemap.xml
Sitemap: http://example.com/wp-sitemap.xml.gz

# Версія коду: 2.0
# Не забудьте змінити 'example.com' на ваш сайт.

Директиви (розбір коду)

User-agent:

Визначає для якого робота буде працювати блок правил, написаний після цього рядка. Тут можливі два варіанти:

1. User-agent: *– Вказує, що правила після цього рядка будуть працювати для всіх пошукових роботів.

2. User-agent: ИМЯ_РОБОТА– Вказує конкретного робота, для якого працюватиме блок правил. Наприклад: User-agent: Yandex, User-agent: Googlebot.

Можливі роботи (боти) Яндекса:

• YandexBot– Основний робот, що індексує.
• YandexImages– Індексатор Яндекс.Картинок.
• YandexMedia– Індексує мультимедійні дані.
• YandexPagechecker– Парс мікророзмітку.
• YandexDirect— завантажує інформацію про контент сайтів-партнерів Рекламної мережі, щоб уточнити їхню тематику для підбору релевантної реклами, особливим чином інтерпретує robots.txt .
• Повний список роботів Яндекса .

Можливі роботи (роботи) Google:

• Googlebot– Основний робот, що індексує.
• Googlebot-Image– Індексує зображення.
• Mediapartners-Google– Робот, що відповідає за розміщення реклами на сайті. Важливим є для тих, у кого крутиться реклама від AdSense. Завдяки цьому user-agent ви можете керувати розміщенням реклами забороняючи або дозволяючи її на тих чи інших сторінках.
• Повний список роботів Google .

Disallow:

Забороняє роботам “ходити” за посиланнями, в яких зустрічається зазначений підрядок:

• Disallow: /cgi-bin– Закриває каталог скриптів на сервері.
• Disallow: *?s=– Закриває сторінки пошуку.
• Disallow: */page/– Закриває всі види пагінації.
• Disallow: */embed$— закриває всі URL, що закінчуються на /embed.

Приклад додавання нового правила. Допустимо нам потрібно закрити від індексації всі записи в категорії news . Для цього додаємо правило:

Disallow: /news

Воно заборонити роботам ходити за посиланнями такого виду:

• http://example.com/news
• http://example.com/news/drugoe-nazvanie/

Якщо потрібно закрити будь-які входження /news , то пишемо:

Disallow: */news

Закриє:

• http://example.com/news
• http://example.com/my/news/drugoe-nazvanie/
• http://example.com/category/newsletter-nazvanie.html

Докладніше вивчити директиви robots.txt ви можете на сторінці допомоги Яндекса . Майте на увазі, що не всі правила, описані там, працюють для Google.

ВАЖЛИВО про кирилицю: роботи не розуміють кирилицю, її їм потрібно надавати в кодованому вигляді. Наприклад:

Disallow: /каталог # неправильно.
Disallow: /%D0%BA%D0%B0%D1%82%D0%B0%D0%BB%D0%BE%D0%B3 # правильно.

Allow:

У рядку
Allow: */uploadsми свідомо дозволяємо індексувати сторінки, в яких зустрічається
/uploads. Це обов’язково, т.к. вище ми забороняємо індексувати сторінки, що починаються з
/wp-, а
/wp- входить у
/wp-content/uploads . Тому, щоб перебити правило
Disallow: /wp-потрібний рядок
Allow: */uploads, адже за посиланнями типу
/wp-content/uploads/… у нас можуть лежати картинки, які повинні індексуватися, так само там можуть лежати якісь завантажені файли, які нема чого приховувати.


Allow:може бути розташована “до” або “після”
Disallow:. При читанні правил роботи їх спочатку сортують, потім читають, тому немає значення де знаходиться
Allow:,
Disallow:. Докладніше про сортування
дивіться нижче .

Sitemap:

Правило
Sitemap: http://example.com/sitemap.xmlвказує роботу на файл із карткою сайту у форматі XML. Якщо у вас на сайті є такий файл, пропишіть повний шлях до нього. Таких файлів може бути кілька, тоді необхідно вказати шлях до кожного файлу окремо.

ВАЖЛИВО: Сортування правил

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 та документація

Перевірити чи правильно працюють правила можна за наступними посиланнями:

• Яндекс: http://webmaster.yandex.ru/robots.xml .

• Google: https://www.google.com/webmasters/tools/robots-testing-tool Потрібна авторизація та наявність сайту на панелі веб-майстра.

• Яндекс документація robots.txt .

• Google документація robots.txt

• Сервіс для створення файлу robots.txt: http://pr-cy.ru/robots/
• Сервіс для створення та перевірки robots.txt: https://seolib.ru/tools/generate/robots/

robots.txt у WordPress

У WordPress запит на сторінку /robots.txtобробляється окремо і для нього “нальоту” через PHP створюється контент файлу robots.txt . Тому не рекомендується фізично створювати файл robots.txt у корені сайту! Тому що за такого підходу ніякий плагін або код не зможе нормально змінити цей файл, а ось динамічне створення контенту для сторінки /robots.txtдозволить його змінювати.

Змінити зміст robots.txt можна через:

• Плагін https://ua.wordpress.org/plugins/pc-robotstxt/ або йому подібний.
• Хук robots_txt .
• Хук do_robotstxt .

Розглянемо як використовувати обидва хуки.

robots_txt

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php

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

Цей хук дозволяє доповнити вже наявні дані файлу robots.txt . Код можна вставити у файл теми functions.php .

// Доповнимо базовий robots.txt
// -1 до wp-sitemap.xml
add_action( 'robots_txt', 'wp_kama_robots_txt_append', -1);

function wp_kama_robots_txt_append( $output ){

	$str = '
	Disallow: /cgi-bin # Стандартна папка на хостингу.
	Disallow: /? # Усі параметри запиту на головній.
	Disallow: *?s= # Пошук.
	Disallow: *&s= # Пошук.
	Disallow: /search # Пошук.
	Disallow: /author/ # Архів автора.
	Disallow: */embed # Усі вбудовування.
	Disallow: */page/ # Всі види пагінації.
	Disallow: */xmlrpc.php # Файл WordPress API
	Disallow: *utm*= # Посилання з utm-мітками
	Disallow: *openstat= # Посилання з мітками openstat
	';

	$ str = trim ($ str);
	$str = preg_replace( '/^[t ]+(?!#)/mU', '', $str );
	$output .= "$strn";

	return $output;
}

В результаті перейдемо на сторінку /robots.txtі бачимо:

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Disallow: /cgi-bin # Стандартна папка на хостингу.
Disallow: /? # Усі параметри запиту на головній.
Disallow: *?s= # Пошук.
Disallow: *&s= # Пошук.
Disallow: /search # Пошук.
Disallow: /author/ # Архів автора.
Disallow: */embed # Усі вбудовування.
Disallow: */page/ # Всі види пагінації.
Disallow: */xmlrpc.php # Файл WordPress API
Disallow: *utm*= # Посилання з utm-мітками
Disallow: *openstat= # Посилання з мітками openstat

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

Зверніть увагу, що ми доповнили рідні дані ОП, а не замінили їх.

do_robotstxt

Цей хук дозволяє повністю замінити контент сторінки /robots.txt.

add_action( 'do_robotstxt', 'wp_kama_robots_txt');

function wp_kama_robots_txt(){

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

	echo implode("rn", $lines);

	die; // обриваємо роботу PHP
}

Тепер, пройшовши посилання http://site.com/robots.txt побачимо:

User-agent: *
Disallow: /wp-admin/
Disallow: /wp-includes/

Рекомендації

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

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

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

Помилкові рекомендації

• Прописування Sitemap після кожного User-agent
  Це робити не потрібно. Один sitemap повинен бути вказаний один раз у будь-якому місці файлу robots.txt .

• Закрити папки wp-content , wp-includes , cache , plugins , themes
  Це застарілі вимоги. Однак подібні поради я знаходив навіть у статті з пафосною назвою «Найправильніший robots для WordPress 2018»! Для Яндекса та Google краще їх взагалі не закривати. Або закривати «по розумному», як описано вище (Версія 2).

• Закривати сторінки тегів та категорій
  Якщо ваш сайт дійсно має таку структуру, що на цих сторінках контент дублюється і в них немає особливої ​​цінності, краще закрити. Однак нерідко просування ресурсу здійснюється у тому числі за рахунок сторінок категорій та тегування. У цьому випадку можна втратити частину трафіку

• Прописати Crawl-Delay
  Модне правило. Однак його потрібно вказувати лише тоді, коли дійсно є потреба обмежити відвідування роботами вашого сайту. Якщо сайт невеликий і відвідування не створюють значного навантаження на сервер, то обмежувати час «щоб було» буде не найрозумнішою витівкою.

• Ляпи
  Деякі правила я можу зарахувати лише до категорії «блогер не подумав». Наприклад: Disallow: /20 – за таким правилом не тільки закриєте всі архіви, але й заодно всі статті про 20 способів або 200 порад, як зробити світ кращим

Спірні рекомендації

• Закривати від індексації сторінки пагінації/page/
  Це робити не потрібно. Для таких сторінок налаштовується тег rel="canonical", таким чином, такі сторінки теж відвідуються роботом і на них враховуються розташовані товари/статті, а також враховується внутрішня маса посилань.

• Коментарі
  Деякі хлопці радять закривати від індексування коментарі Disallow: /commentsта Disallow: */comment-*.

• Відкрити папку uploads тільки для Googlebot-Image та YandexImages

  User-agent: Googlebot-Image
  Allow: /wp-content/uploads/
  User-agent: YandexImages
  Allow: /wp-content/uploads/

  Порада досить сумнівна, т.к. Для ранжування сторінки потрібна інформація про те, які зображення та файли на ній розміщені.

Джерело за рекомендаціями .

Нестандартні Директиви

Clean-param

Google не розумію цієї директиви. Вказує роботу, що URL-адреса сторінки містить GET-параметри, які не потрібно враховувати при індексуванні. Такими параметрами може бути ідентифікатори сесій, користувачів, мітки UTM, тобто. все те, що не впливає на вміст сторінки.

Заповнюйте директиву Clean-param максимально повно та підтримуйте її актуальність. Новий параметр, що не впливає на вміст сторінки, може призвести до появи сторінок-дублів, які не повинні потрапити в пошук. Через велику кількість таких сторінок робот повільніше обходить сайт. Отже, важливі зміни довше не потраплять у результати пошуку. Робот Яндекса, використовуючи цю директиву, не буде багаторазово перезавантажувати інформацію, що дублюється. Таким чином, збільшиться ефективність обходу вашого сайту, знизиться навантаження на сервер.

Наприклад, на сайті є сторінки, в яких параметр refвикористовується тільки для того, щоб відстежити з якого ресурсу було зроблено запит і не змінює вміст, за всіма трьома адресами буде показано одну і ту ж сторінку:

example.com/dir/bookname?ref=site_1
example.com/dir/bookname?ref=site_2
example.com/dir/bookname?ref=site_3

Якщо вказати директиву так:

User-agent: Yandex
Clean-param: ref /dir/bookname

то робот Яндекса зведе всі адреси сторінки до одного:

example.com/dir/bookname

Приклад очищення кількох параметрів відразу: refі sort:

Clean-param: ref&sort /dir/bookname

Crawl-delay (застаріла)

User-agent: Yandex
Disallow: /wp-admin
Disallow: /wp-includes
Crawl-delay: 1.5

User-agent: *
Disallow: /wp-admin
Disallow: /wp-includes
Allow: /wp-*.gif

Google не розуміє цієї директиви. Таймаут його роботам можна вказати на панелі вебмайстра.

Яндекс перестав враховувати Crawl-delay

Детальніше Яндекс перестав враховувати Crawl-delay :

Проаналізувавши листи за останні два роки на нашу підтримку з питань індексування, ми з’ясували, що однією з основних причин повільного завантаження документів є неправильно налаштована директива Crawl-delay в robots.txt […] Для того, щоб власникам сайтів не довелося більше про це турбуватися щоб усі дійсно потрібні сторінки сайтів з’являлися та оновлювались у пошуку швидко, ми вирішили відмовитись від обліку директиви Crawl-delay.

Для чого була потрібна директива Crawl-delay

Коли робот сканує сайт як божевільний і це створює надмірне навантаження на сервер. Роботу можна попросити «зменшити оберти». Для цього можна використовувати директиву Crawl-delay . Вона вказує час у секундах, який робот повинен простоювати (чекати) для сканування кожної наступної сторінки сайту.

Host (застаріла)

Google Директиву Host ніколи не підтримував, а Яндекс повністю відмовляється від неї. Host можна сміливо видаляти з robots.txt . Замість Host потрібно налаштовувати 301 редирект із усіх дзеркал сайту на головний сайт (головне дзеркало).

Докладніше читайте на сайті Яндекса .

Висновок

Важливо пам’ятати, що зміни в robots.txt на робочому сайті будуть помітні лише через кілька місяців (2-3 місяці).

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

–