Інтернет Windows Android

Які сторінки закривати від індексації і як. Заборона індексації сторінки в мета-теге robots

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

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

1. При просуванні сайту їх власники не замислюються про те, що бачить і додає в індекс пошуковий бот. У цьому випадку може виникнути ситуація, коли в індексі більше сміттєвих сторінок, ніж просуваються, а самі сторінки перевантажені.

2. Навпаки, власники надто завзято взялися за чистку сайту. Разом з непотрібною інформацією можуть ховатися і важливі для просування і оцінки сторінок дані.

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

контент

Проблеми, пов'язані із закриттям контенту на сайті:

Сторінка оцінюється пошуковими роботами комплексно, а не тільки по текстових показниками. Захоплюючись закриттям різних блоків, часто віддаляється і важлива для оцінки корисності і ранжирування інформація.

Наведемо приклад найбільш частих помилок:
- ховається шапка сайту. У ній зазвичай розміщується контактна інформація, посилання. Якщо шапка сайту закрита, пошуковики можуть не впізнати, що ви подбали про відвідувачів і помістили важливу інформаціюна видному місці;

- ховаються від індексації фільтри, форма пошуку, сортування. Наявність таких можливостей у інтернет-магазину - важливий комерційний показник, який краще показати, а не ховати.
- ховається інформація про оплату та доставку. Це роблять, щоб підвищити унікальність на товарних картках. А адже це теж інформація, яка повинна бути на якісної товарної картці.
- зі сторінок «вирізується» меню, погіршуючи оцінку зручності навігації по сайту.

Навіщо на сайті закривають частину контенту?
Зазвичай є кілька цілей:
- зробити на сторінці акцент на основний контент, прибравши з індексу допоміжну інформацію, службові блоки, меню;
- зробити сторінку більш унікальною, корисною, прибравши дублюються на сайті блоки;
- прибрати «зайву» текст, підвищити текстову релевантність сторінки.

Всього цього можна досягти без того, щоб ховати частину контенту!
У вас дуже велике меню?
Виводите на сторінках тільки ті пункти, які безпосередньо відносяться до розділу.

Багато можливостей вибору в фільтрах?
Виводите в основному коді тільки популярні. Довантажувати інші варіанти, тільки якщо користувач натисне кнопку «показати все». Так, тут використовуються скрипти, але ніякого обману немає - скрипт спрацьовує на вимогу користувача. Знайти всі пункти пошуковик зможе, але при оцінці вони не отримають таке ж значення, як основний контент сторінки.

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

Пошукові роботи хоч і далекі від ідеалу, але постійно удосконалюються. Вже зараз Google показує приховування скриптів від індексування як помилку в панелі Google Search Console (вкладка «Заблоковані ресурси»). Чи не показувати частину контенту роботам дійсно може бути корисним, але це не метод оптимізації, а, скоріше, тимчасові «милиці», які варто використовувати тільки при гострій потребі.

Ми рекомендуємо:
- ставитися до приховування контенту, як до «милиці», і вдаватися до нього тільки в крайніх ситуаціях, прагнучи доопрацювати саму сторінку;
- видаляючи зі сторінки частину контенту, орієнтуватися не тільки на текстові показники, а й оцінювати зручність і інформацію, яка впливає на;
- перед тим як ховати контент, проводити експеримент на декількох тестових сторінках. Пошукові боти вміють розбирати сторінки і ваші побоювання про зниження релевантності можуть виявитися марними.

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

тег noindex

У цього методу є кілька недоліків. Перш за все цей тег враховує тільки Яндекс, тому для приховування тексту від Google він марний. Крім цього, важливо розуміти, що тег забороняє індексувати і показувати в пошуковій видачі тільки текст. На решті контент, наприклад, посилання, він не поширюється.

Підтримка Яндекса не особливо поширюється про те, як працює noindex. Трохи більше інформації є в одному з обговорень в офіційному блозі.

Питання користувача:

«Не до кінця зрозуміла механіка дії і вплив на ранжування тега текст. Далі поясню, чому так спантеличені. А зараз - є 2 гіпотези, хотілося б знайти істину.

№1 Noindex не впливає на ранжування / релевантність сторінки взагалі

При цьому припущенні: єдине, що він робить - закриває частину контенту від появи в пошуковій видачі. При цьому вся сторінка розглядається цілком, включаючи закриті блоки, релевантність і пов'язані параметри (унікальність; відповідність і т. П.) Для неї обчислюється відповідно до всього має в коді контенту, навіть закритому.

№2 Noindex впливає на ранжування і релевантність, так як закритий в тег контент не оцінює взагалі. Відповідно, все навпаки. Сторінка ранжируватиметься відповідно до відкритим для роботів контентом. »

В яких випадках може бути корисний тег:
- якщо є підозри, що сторінка знижена у видачі Яндекса через переоптімізаціі, але при цьому займає топові позиції з важливих фразам в Google. Потрібно розуміти, що це швидке і тимчасове рішення. Якщо весь сайт потрапив під «Баден-Баден», noindex, як неодноразово підтверджували представники Яндекса, не допоможе;
- щоб приховати загальну службову інформацію, яку ви через корпоративні чи юридичних нормативів повинні вказувати на сторінці;
- для коригування сніпетів в Яндексі, якщо в них потрапляє небажаний контент.

Приховування контенту за допомогою AJAX

це універсальний метод. Він дозволяє заховати контент і від Яндекса, і від Google. Якщо хочете почистити сторінку від розмиває релевантність контенту, краще використовувати саме його. Представники ПС такий метод, звичайно, не вітаю і рекомендують, щоб пошукові роботи бачили той же контент, що і користувачі.
Технологія використання AJAX широко поширена і якщо не займатися явним клоакінг, санкції за її використання не загрожують. Недолік методу - вам все-таки доведеться закривати доступ до скриптів, хоча і Яндекс і Google цього не рекомендують робити.

сторінки сайту

Для успішного просування важливо не тільки позбутися від зайвої інформації на сторінках, а й очистити пошуковий індекссайту від малокорисних сміттєвих сторінок.
По-перше, це прискорить індексацію основних просуваються сторінок сайту. По-друге, наявність в індексі великого числасміттєвих сторінок буде негативно впливати на оцінку сайту і його просування.

Відразу перерахуємо сторінки, які доцільно ховати:

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

Розглянемо способи, якими можна закрити сторінки від індексації.

Закрити в robots.txt

Це не найкращий метод.

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

По-друге, заборона в файлі robots не є гарантією того, що сторінка не потрапить в індекс.

Ось що Google пише про це у своїй довідці:

метатег noindex

Щоб гарантовано виключити сторінки з індексу, краще використовувати цей метатег.

Нижче наведемо варіант метатега, який розуміють обидва пошукача:

Важливий момент!

Щоб Googlebot побачив метатег noindex, потрібно відкрити доступ до сторінок, закритим у файлі robots.txt. Якщо цього не зробити, робот може просто не зайти на ці сторінки.

Заголовки X-Robots-Tag

Суттєва перевага такого методу в тому, що заборона можна розміщувати не тільки в коді сторінки, але і через кореневої файл.htaccess.

Цей метод не дуже поширений в Рунеті. Вважаємо, основна причина такої ситуації в тому, що Яндекс цей метод довгий часне підтримував.
У цьому році співробітники Яндекса написали, що метод тепер підтримується.

Відповідь підтримки докладним не назвеш))). Перш ніж переходити на заборону індексації, використовуючи X-Robots-Tag, краще переконатися в роботі цього способу під Яндекс. Свої експерименти на цю тему ми поки не ставили, але, можливо, зробимо найближчим часом.

Захист за допомогою пароля

Якщо потрібно приховати весь сайт, наприклад, тестову версію, також рекомендуємо використовувати саме цей метод. Мабуть, єдиний недолік - можуть виникнути складності в разі необхідності просканувати домен, прихований під паролем.

Виключити появу сміттєвих сторінок c допомогою AJAX

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

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

Складність цього методу в тому, що зазвичай його не можна застосувати відразу для всіх випадків. Частина формованих сторінок використовується для просування.

Наприклад, сторінки фільтрів. Для «холодильник + Samsung + білий» нам потрібна сторінка, а для «холодильник + Samsung + білий + двокамерний + no frost» - вже немає.

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

Використовувати методи заборони індексації від пошукових алгоритмів

«Параметри URL» в Google Search Console

Цей інструмент дозволяє вказати, як ідентифікувати появу в URL сторінокнових параметрів.

Директива Clean-param в robots.txt

В Яндексі аналогічну заборону для параметрів URL можна прописати, використовуючи директиву Clean-param.
Почитати про це можна.

Канонічні адреси, як профілактика появи сміттєвих сторінок на сайті
Цей метатег був створений спеціально для боротьби з дублями і сміттєвими сторінками на сайті. Ми рекомендуємо прописувати його на всьому сайті, як профілактику появи в індексі дублі і сміттєвих сторінок.

Інструменти точкового видалення сторінок з індексу Яндекса і Google

Якщо виникла ситуація, коли потрібно терміново видалити інформацію з індексу, не чекаючи, поки ваш заборона побачать пошукові роботи, можна використовувати інструменти з панелі Яндекс.Вебмайстер і Google Search Console.

В Яндексі це «Видалити URL»:

У Google Search Console «Видалити URL-адресу»:

внутрішні посилання

Внутрішні посилання закриваються від індексації для перерозподілу внутрішніх ваг на основні обнародувано сторінки. Але справа в тому, що:
- такий перерозподіл може погано відбитися на загальних зв'язкахміж сторінками;
- посилання з шаблонних наскрізних блоків зазвичай мають меншу вагу або можуть взагалі не враховуватися.

Розглянемо варіанти, які використовуються для приховування посилань:

тег noindex

Щоб приховати посилань цей тег марний. Він поширюється тільки на текст.

Атрибут rel = "nofollow"

Зараз атрибут не дозволяє зберігати вагу на сторінці. При використанні rel = "nofollow" вага просто втрачається. Саме по собі використання тега для внутрішніх посилань виглядає не особливо логічно.

Приховування посилань за допомогою скриптів

Це фактично єдиний робочий метод, за допомогою якого можна заховати посилання від пошукових систем. Можна використовувати Аjax і довантажувати блоки посилань вже після завантаження сторінки або додавати посилання, підміняючи скриптом тег на . При цьому важливо враховувати, що пошукові алгоритми вміють розпізнавати скрипти.

Як і у випадку з контентом - це «милиця», який іноді може вирішити проблему. Якщо ви не впевнені, що отримаєте позитивний ефект від захованого блоку посилань, краще такі методи не використовувати.

висновок

Видалення зі сторінки об'ємних наскрізних блоків дійсно може давати позитивний ефект для ранжирування. Робити це краще, скорочуючи сторінку, і виводячи на ній тільки потрібний відвідувачам контент. Ховати контент від пошукача - милиця, який варто використовувати тільки в тих випадках, коли скоротити іншими способами наскрізні блоки не можна.

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

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

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

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

Більшість роботів добре спроектовані і не створюють будь-яких проблем для власників сайтів. Але якщо бот написаний дилетантом або «щось пішло не так», то він може створювати істотне навантаження на сайт, який він обходить. До речі, павуки зовсім на заходять на сервер подібно до вірусів - вони просто запитують потрібні їм сторінки віддалено (по суті це аналоги браузерів, але без функції перегляду сторінок).

Robots.txt - директива user-agent і боти пошукових систем

Роботс.тхт має зовсім не складний синтаксис, який дуже докладно описаний, наприклад, в хелпе яндексаі хелпе Гугла. Зазвичай в ньому вказується, для якого пошукового бота призначені описані нижче директиви: ім'я бота ( " User-agent"), Що дозволяють (" Allow") І забороняють (" Disallow"), А також ще активно використовується" Sitemap "для вказівки пошуковим системам, де саме знаходиться файл карти.

Стандарт створювався досить давно і щось було додано вже пізніше. Є директиви і правила оформлення, які будуть зрозумілі тільки роботами певних пошукових систем. В рунеті інтерес представляють в основному тільки Яндекс і Гугл, а значить саме з їх Хелп по складанню robots.txt слід ознайомитися особливо детально (посилання я навів у попередньому абзаці).

Наприклад, раніше для пошукової системи Яндекс було корисним вказати, вашого вебпроектів є головним в спеціальній директиві "Host", яку розуміє тільки цей пошуковик (ну, ще й Майл.ру, бо у них пошук від Яндекса). Правда, на початку 2018 Яндекс все ж скасував Hostі тепер її функції як і у інших пошукачів виконує 301-редирект.

Якщо навіть у вашого ресурсу немає дзеркал, то корисно буде вказати, який з варіантів написання є головним -.

Тепер поговоримо трохи про синтаксис цього файлу. Директиви в robots.txt мають такий вигляд:

<поле>:<пробел><значение><пробел> <поле>:<пробел><значение><пробел>

Правильний код повинен містити хоча б одну директиву «Disallow»після кожного запису «User-agent». Порожній файл передбачає дозвіл на індексування всього сайту.

User-agent

Директива «User-agent»повинна містити назву пошукового бота. За допомогою неї можна налаштувати правила поведінки для кожного конкретного пошукача (наприклад, створити заборона індексації окремої папки тільки для Яндекса). Приклад написання «User-agent», адресований усім роботам зайшли на ваш ресурс, виглядає так:

User-agent: *

Якщо ви хочете в «User-agent» задати певні умови тільки для якогось одного бота, наприклад, Яндекса, то потрібно написати так:

User-agent: Yandex

Назва роботів пошукових систем і їх роль у файлі robots.txt

Бот кожної пошукової системимає свою назву (наприклад, для Рамблера це StackRambler). Тут я приведу список найвідоміших з них:

Google http://www.google.com Googlebot Яндекс http://www.ya.ru Yandex Бінг http://www.bing.com/ bingbot

У великих пошукових систем іноді, крім основних ботів, Є також окремі екземпляри для індексації блогів, новин, зображень і т.д. Багато інформації по різновидах ботів ви можете почерпнути (для Яндекса) і (для Google).

Як бути в цьому випадку? Якщо потрібно написати правило заборони індексації, яке повинні виконати всі типи роботів Гугла, то використовуйте назву Googlebot і всі інші павуки цього пошуковика теж послухають. Однак, можна заборона давати тільки, наприклад, на індексацію картинок, вказавши в якості User-agent бота Googlebot-Image. Зараз це не дуже зрозуміло, але на прикладах, я думаю, буде простіше.

Приклади використання директив Disallow і Allow в роботс.тхт

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

  1. Наведений нижче код дозволяє всім роботам (на це вказує зірочка в User-agent) проводити індексацію всього вмісту без будь-яких винятків. це задається порожній директивою Disallow. User-agent: * Disallow:
  2. Наступний код, навпаки, повністю забороняє всім пошуковим системам додавати в індекс сторінки цього ресурсу. Встановлює це Disallow з «/» в поле значення. User-agent: * Disallow: /
  3. У цьому випадку буде заборонятися всім роботам переглядати вміст каталогу / image / (http://mysite.ru/image/ - абсолютний шлях до цього каталогу) User-agent: * Disallow: / image /
  4. Щоб заблокувати один файл, досить буде прописати його абсолютний шлях до нього (читайте): User-agent: * Disallow: /katalog1//katalog2/private_file.html

    Забігаючи трохи вперед скажу, що простіше використовувати символ зірочки (*), щоб не писати повний шлях:

    Disallow: /*private_file.html

  5. У наведеному нижче прикладі будуть заборонені директорія «image», а також всі файли і директорії, що починаються з символів «image», т. Е. Файли: «image.htm», «images.htm», каталоги: «image», « images1 »,« image34 »і т. д.): User-agent: * Disallow: / image Справа в тому, що за замовчуванням в кінці запису мається на увазі зірочка, яка замінює будь-які символи, в тому числі і їх відсутність. Читайте про це нижче.
  6. За допомогою директиви Allowми дозволяємо доступ. Добре доповнює Disallow. Наприклад, таким ось умовою пошуковому роботу Яндекса ми забороняємо викачувати (індексувати) всі, крім веб-сторінок, адреса яких починається з / cgi-bin: User-agent: Yandex Allow: / cgi-bin Disallow: /

    Ну, або такий ось очевидний приклад використання зв'язки Allow і Disallow:

    User-agent: * Disallow: / catalog Allow: / catalog / auto

  7. При описі шляхів для директив Allow-Disallow можна використовувати символи "*" І "$", Задаючи, таким чином, певні логічні вирази.
    1. символ "*" (Зірочка)означає будь-яку (в тому числі порожню) послідовність символів. Наступний приклад забороняє всім пошуковим системам індексацію файлів з розширення «.php»: User-agent: * Disallow: * .php $
    2. Навіщо потрібен на кінці знак $ (долара)? Справа в тому, що за логікою складання файлу robots.txt, в кінці кожної директиви як би дописується умолчательную зірочка (її немає, але вона як би є). Наприклад ми пишемо: Disallow: / images

      Маючи на увазі, що це те ж саме, що:

      Disallow: / images *

      Тобто це правило забороняє індексацію всіх файлів (веб-сторінок, картинок і інших типів файлів) адреса яких починається з / images, а далі слід все що завгодно (див. приклад вище). Так ось, символ $просто скасовує цю умолчательную (непроставляемую) зірочку на кінці. наприклад:

      Disallow: / images $

      Забороняє тільки індексацію файлу / images, але не /images.html або /images/primer.html. Ну, а в першому прикладі ми заборонили індексацію тільки файлів закінчуються на.php (мають таке розширення), щоб нічого зайвого не зачепити:

      Disallow: * .php $

  • У багатьох двигунах користувачі (людино-зрозумілі урли), в той час як урли, що генеруються системою, мають знак питання "?" в адресі. Цим можна скористатися і написати таке правило в robots.txt: User-agent: * Disallow: / *?

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

  • Директиви Sitemap і Host (для Яндекса) в Robots.txt

    Для уникнення виникнення неприємних проблем з дзеркалами сайту, раніше рекомендувалося додавати в robots.txt директиву Host, яка вказував боту Yandex на головне дзеркало.

    Директива Host - вказує головне дзеркало сайту для Яндекса

    Наприклад, раніше, якщо ви ще не перейшли на захищений протокол, Вказувати в Host потрібно було не повний Урл, а доменне ім'я(Без http: //, т.е..ru). Якщо ж вже перейшли на https, то вказувати потрібно буде повний Урл (типу https://myhost.ru).

    Чудовий інструмент для боротьби з дублями контенту - пошуковик просто не буде індексувати сторінку, якщо в Canonical прописаний інший урл. Наприклад, для такої сторінки мого блогу (сторінки з пагінацією) Canonical вказує на https: // сайт і ніяких проблем з дублюванням тайтлів виникнути не повинно.

    Але це я відволікся ...

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

    Наприклад, в WordPress сторінкиз дуже схожим вмістом можуть потрапити в індекс пошукових систем, якщо дозволена індексація і вмісту рубрик, і вмісту архіву тегів, і вмісту тимчасових архівів. Але якщо за допомогою описаного вище мета-тега Robots створити заборона для архіву тегів і тимчасового архіву (можна теги залишити, а заборонити індексацію вмісту рубрик), то дублювання контенту не виникне. Як це зробити описано за посиланням наведеної трохи вище (на плагін ОлІнСеоПак)

    Підводячи підсумок скажу, що файл Роботс призначений для налаштування загальних правил заборони доступу в цілі директорії сайту, або в файли і папки, в назві яких присутні задані символи (по масці). Приклади завдання таких заборон ви можете подивитися трохи вище.

    Тепер давайте розглянемо конкретні приклади Роботс, призначеного для різних движків - Joomla, WordPress і SMF. Природно, що всі три варіанти, створені для різних CMS, будуть істотно (якщо не сказати кардинально) відрізнятися один від одного. Правда, у всіх у них буде один загальний момент, І момент цей пов'язаний з пошуковою системою Яндекс.

    Оскільки в рунеті Яндекс має досить велику вагу, то потрібно враховувати всі нюанси його роботи, і тут нам допоможе директива Host. Вона в явній формі вкаже цього пошуковику головне дзеркало вашого сайту.

    Для неї радять використовувати окремий блог User-agent, призначений тільки для Яндекса (User-agent: Yandex). Це пов'язано з тим, що інші пошукові системи можуть не розуміти Host і, відповідно, її включення в запис User-agent, призначену для всіх пошукових систем (User-agent: *), може призвести до негативних наслідків і неправильної індексації.

    Як йде справа насправді - сказати важко, бо алгоритми роботи пошуку - це річ в собі, тому краще зробити так, як радять. Але в цьому випадку доведеться продублювати в директиві User-agent: Yandex все ті правила, що ми задали User-agent: *. Якщо ви залишите User-agent: Yandex з порожнім Disallow:, то таким чином ви дозволите Яндексу заходити куди завгодно і тягнути все підряд в індекс.

    Robots для WordPress

    Не буду наводити приклад файлу, який рекомендують розробники. Ви і самі можете його подивитися. Багато блогерів взагалі не обмежують ботів Яндекса і Гугла в їх прогулянках по вмісту движка WordPress. Найчастіше в блогах можна зустріти Роботс, автоматично заповнений плагіном.

    Але, по-моєму, все-таки слід допомогти пошуку в нелегкій справі відсіювання зерен від плевел. По-перше, на індексацію цього сміття піде багато часу у ботів Яндекса і Гугла, і може зовсім не залишитися часу для додавання в індекс веб-сторінок з вашими новими статтями. По-друге, боти, що лазять по сміттєвих файлів движка, будуть створювати додаткове навантаження на сервер вашого хоста, що не є добре.

    Мій варіант цього файлу ви можете самі подивитися. Він старий, давно не змінювався, але я намагаюся дотримуватися принципу «не чини те, що не ламалося», а вам вже вирішувати: використовувати його, зробити свій або ще у когось підглянути. У мене там ще заборона індексації сторінок з пагінацією був прописаний до недавнього часу (Disallow: * / page /), але недавно я його прибрав, сподіватимемося на Canonical, про який писав вище.

    А взагалі, єдино правильного файлудля WordPress, напевно, не існує. Можна, звичайно ж, реалізувати в ньому будь-які передумови, але хто сказав, що вони будуть правильними. Варіантів ідеальних robots.txt в мережі багато.

    Наведу дві крайності:

    1. можна знайти мегафайліще з докладними поясненнями (символом # відокремлюються коментарі, які в реальному файлі краще буде видалити): User-agent: * # загальні правила для роботів, крім Яндекса і Google, # тому для них правила нижче Disallow: / cgi-bin # папка на хостингу Disallow: /? # Всі параметри запиту на головній Disallow: / wp- # всі файли WP: / wp-json /, / wp-includes, / wp-content / plugins Disallow: / wp / # якщо є підкаталог / wp /, де встановлена ​​CMS ( якщо немає, # правило можна видалити) Disallow: *? s = # пошук Disallow: * & s = # пошук Disallow: / search / # пошук Disallow: / author / # архів автора Disallow: / users / # архів авторів Disallow: * / trackback # трекбеки, повідомлення в коментарях про появу відкритої # посилання на статтю Disallow: * / feed # все фіди Disallow: * / rss # rss фід Disallow: * / embed # все вбудовування Disallow: * / wlwmanifest.xml # xml-файл маніфесту Windows Live Writer (якщо не використовуєте, # правило можна видалити) Disallow: /xmlrpc.php # файл WordPress API Disallow: * utm = # посилання з utm-мітками Disallow: * openstat = # посилання з мітками openstat Allow: * / uploads # відкриваємо папку з файлами uploads User-agent: GoogleBot # правила для Google (коментарів не дублюю) Disallow: / cgi-bin Disallow: /? Disallow: / wp- Disallow: / wp / Disallow: *? S = Disallow: * & s = Disallow: / search / Disallow: / author / Disallow: / users / Disallow: * / trackback Disallow: * / feed Disallow: * / rss Disallow: * / embed Disallow: * / wlwmanifest.xml Disallow: /xmlrpc.php Disallow: * utm = Disallow: * openstat = Allow: * / uploads Allow: /*/*.js # відкриваємо js-скрипти всередині / wp - (/ * / - для пріоритету) Allow: /*/*.css # відкриваємо css-файли всередині / wp- (/ * / - для пріоритету) Allow: /wp-*.png # картинки в плагінах, cache папці і т.д. Allow: /wp-*.jpg # картинки в плагінах, cache папці і т.д. Allow: /wp-*.jpeg # картинки в плагінах, cache папці і т.д. Allow: /wp-*.gif # картинки в плагінах, cache папці і т.д. Allow: /wp-admin/admin-ajax.php # використовується плагінами, щоб не блокувати JS і CSS User-agent: Yandex # правила для Яндекса (коментарів не дублюю) Disallow: / cgi-bin Disallow: /? Disallow: / wp- Disallow: / wp / Disallow: *? S = Disallow: * & s = Disallow: / search / Disallow: / author / Disallow: / users / Disallow: * / trackback Disallow: * / feed Disallow: * / rss Disallow: * / embed Disallow: * / wlwmanifest.xml Disallow: /xmlrpc.php Allow: * / uploads Allow: /*/*.js Allow: /*/*.css Allow: /wp-*.png Allow: /wp-*.jpg Allow: /wp-*.jpeg Allow: /wp-*.gif Allow: /wp-admin/admin-ajax.php Clean-Param: utm_source & utm_medium & utm_campaign # Яндекс рекомендує не закривати # від індексування, а видаляти параметри міток, # Google такі правила не підтримує Clean-Param: openstat # аналогічно # Вкажіть один або декілька файлів Sitemap (дублювати для кожного User-agent # не потрібно). Google XML Sitemapстворює 2 карти сайту, як в прикладі нижче. Sitemap: http://site.ru/sitemap.xml Sitemap: http://site.ru/sitemap.xml.gz # Вкажіть головне дзеркало сайту, як в прикладі нижче (з WWW / без WWW, якщо HTTPS # то пишемо протокол, якщо потрібно вказати порт, вказуємо). Команду Host розуміє # Яндекс і Mail.RU, Google не враховує. Host: www.site.ru
    2. А ось можна взяти на озброєння приклад мінімалізму: User-agent: * Disallow: / wp-admin / Allow: /wp-admin/admin-ajax.php Host: https://site.ru Sitemap: https: // site. ru / sitemap.xml

    Істина, напевно, лежить десь посередині. Ще не забудьте прописати мета-тег Robots для «зайвих» сторінок, наприклад, за допомогою чудесного плагіна -. Він же допоможе і Canonical налаштувати.

    Правильний robots.txt для Joomla

    User-agent: * Disallow: / administrator / Disallow: / bin / Disallow: / cache / Disallow: / cli / Disallow: / components / Disallow: / includes / Disallow: / installation / Disallow: / language / Disallow: / layouts / Disallow: / libraries / Disallow: / logs / Disallow: / modules / Disallow: / plugins / Disallow: / tmp /

    В принципі, тут практично все враховано і працює він добре. Єдине, в нього слід додати окреме правило User-agent: Yandex для вставки директиви Host, що визначає головне дзеркало для Яндекса, а так само вказати шлях до файлу Sitemap.

    Тому в остаточному вигляді правильний robots для Joomla, на мою думку, має виглядати так:

    User-agent: Yandex Disallow: / administrator / Disallow: / cache / Disallow: / includes / Disallow: / installation / Disallow: / language / Disallow: / libraries / Disallow: / modules / Disallow: / plugins / Disallow: / tmp / Disallow: / layouts / Disallow: / cli / Disallow: / bin / Disallow: / logs / Disallow: / components / Disallow: / component / Disallow: / component / tags * Disallow: / * mailto / Disallow: /*.pdf Disallow : / *% Disallow: /index.php Host: vash_sait.ru (або www.vash_sait.ru) User-agent: * Allow: /*.css?*$ Allow: /*.js?*$ Allow: / * .jpg? * $ Allow: /*.png?*$ Disallow: / administrator / Disallow: / cache / Disallow: / includes / Disallow: / installation / Disallow: / language / Disallow: / libraries / Disallow: / modules / Disallow : / plugins / Disallow: / tmp / Disallow: / layouts / Disallow: / cli / Disallow: / bin / Disallow: / logs / Disallow: / components / Disallow: / component / Disallow: / * mailto / Disallow: / *. pdf Disallow: / *% Disallow: /index.php Sitemap: http: // шлях до вашої карті XML формату

    Так, ще зверніть увагу, що в другому варіанті є директиви Allow, що дозволяють індексацію стилів, скриптів і картинок. Написано це спеціально для Гугла, бо його Googlebot іноді лається, що в Роботс заборонена індексація цих файлів, наприклад, з папки з використовуваної темою оформлення. Навіть погрожує за це знижувати в ранжируванні.

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

    Удачі вам! До швидких зустрічей на сторінках блогу сайт

    подивитися ще ролики можна перейшовши на
    ");">

    Вам може бути цікаво

    Домени з www і без нього - історія появи, використання 301 редіректу для їх склеювання
    Дзеркала, дублі сторінок і Url адреси - аудит вашого сайту або що може бути причиною краху при його SEO просуванні

    У CMS Joomla є один недолік, це дублі адрес сторінок. Дублі - це коли одна стаття доступна за двома адресами.

    наприклад:

    Детальніше і як прибрати з індексації дублі сторінок в Joomla читаємо під катом.

    У CMS Joomla є один недолік, це дублі адрес сторінок. Дублі - це коли одна стаття доступна за двома адресами. наприклад:

    http: //сайт/dizayn/ikonki-sotsial-noy-seti-vkonrtakte.html

    index.php? option = com_content & view = article & id = 99: vkontakteicons & catid = 5: design & Itemid = 5

    Як з'являються дублі сторінок?Дуже просто, на прикладі вище ми бачимо два посилання на один матеріал. Перше посилання - красива і человекопонятний (ЧПУ посилання), створена компонентом JoomSEF який перетворює все посилання на сайті в такий гарний, легкий для читання вигляд. Друге посилання - внутрішня системна посилання Джумли, і якби компонент Artio JoomSef ні встановлено, то всі посилання на сайті були б як друга - незрозумілі і непривабливі. Тепер від тому наскільки це страшно і як боротися з дублями.

    Наскільки дублі шкідливі для сайту.Я б не називав його дуже великим недоліком, так як на мою думку, пошукові машини не повинні сильно банити і пессімізіровать сайт за такі дублі, так як дублі ці робляться не спеціально, а є частиною CMS системи. Причому, зауважу, дуже популярною системи, на якій зроблені мільйони сайтів, а значить пошуковики навчилися розуміти таку «особливість». Але все таки, якщо є можливість і бажання, то краще такі дублі позакривати від очей великого брата.

    Як боротися з дублями в Joomla та інших cms

    1) Два дубля однієї сторінки, заборона в robots.txt

    Наприклад, в індекс пошукача потрапляють такі дві адреси однієї сторінки:

    http://site.ru/страница.html?replytocom=371
    http://site.ru/страница.html?iframe=true&width=900&height=450

    Для закриття таких дублів в robots.txt потрібно додати:

    Disallow: / *? *
    Disallow: / *?

    Цією дією ми закрили від індексації всі посилання сайту зі знаком «?». Такий варіант підходить для сайтів де включена робота ЧПУ, і нормальні посилання не мають в собі знаків питання - «?».

    2. Використовувати тег rel = "canonical"

    Припустимо на одну сторінку йде два посилання з різними адресами. пошукачам Googleі Yahoo моджно вказати на те яку адресу на сторінку є головним. Для цього в тезі треба прописати тег rel = "canonical". Яндекс цю опцію не підтримує.

    Для Joomla для постановки тега rel = "canonical" я знайшов два розширення, під назвою 1) plg_canonical_v1.2; і 2) 098_mod_canonical_1.1.0. Можете їх потестувати. Але я б вчинив іншим чином і просто заборонив до індексації всі посилання мають в собі знак питання, як показав в прикладі вище.

    3. Заборонити індексування в robots.txt Joomla дублів (сторінки з закінченням index.php) і інших не потрібних сторінок.

    Так як всі дублі сторінок в Joomla починаються з index.php, то можна заборонити їх все до індексації одним рядком в robots.txt - Disallow: /index.php. Також цим самим ми заборонимо дубль головної сторінки, Коли вона доступна за адресою «http://site.ru/» і «http://site.ru/index.php».

    4. Cклейка домену з www і без за допомогою 301 редіректу (переадресація).

    Для склеювання домену з www і без потрібно зробити переадресацію - 301 редирект. Для цього в файле.htaccess прописуємо:

    RewriteEngine on

    Якщо вам потрібно навпаки зробити редирект з http://site.ru на www.site.ru, то запис буде виглядати так:

    RewriteEngine On
    RewriteCond% (HTTP_HOST) ^ site.ru
    RewriteRule (. *) Http://www.site.ru/$1

    5. Директива Host дає визначення основного домену з www або без для Яндекса.

    Для тих веб-майстрів, які щойно створили свій сайт, не поспішайте виконувати ті дії, які я описав в цьому пункті, спочатку потрібно скласти правильний robots.txt прописати директиву Host, цим ви визначите основний домен в очах яндекса.

    Це буде виглядати наступним чином:

    User-Agent: Yandex
    Host: site.ru

    Директиву Host розуміє тільки Яндекс. Google її не розуміє.

    6. Joomla дублі сторінок склеюємо в файле.htaccess.

    Дуже часто головна сторінка сайту на joomla буває доступна за адресою http://site.ru/index.html або http://site.ru/index.рhp, http: //site.ru.html, тобто це дублі головної сторінки (http://site.ru), звичайно від них можна позбутися шляхом закриття їх в robots.txt, але краще це зробити при помощі.htaccess. Для цього в цей файл додати наступне:


    Використовуйте цей код якщо вам потрібно позбавитися від дубля з index.рhp, не забудьте в коді замість http: // ваш сайт.ru /, поставити свій домен.

    Щоб перевірити вийшла у вас чи ні, просто введіть в браузер адресу дубля (http://site.ru/index.рhp), якщо вийшло, то вас перекине на сторінку http://site.ru, також буде відбуватися і з пошуковими ботами і вони не будуть бачити ці дублі.

    І по аналогії склеюємо Joomla дублі з іншими приставками до URI вашої головної сторінки, просто відредагуйте код який я навів вище.

    7. Вказати sitemap в robots.txt

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

    Sitemap: http: //домен.ru/sitemap.xml.gz
    Sitemap: http: //домен.ru/sitemap.xml

    підсумок

    Підщепи підсумок вищесказаного, для Joomla я б прописав ось такі рядки в robots.txt:

    Disallow: /index.php

    Вказати основний хост для Яндекса

    User-Agent: Yandex
    Host: site.ru

    І ось такі рядки в.htaccess

    # Склеювання домену з www і без

    RewriteEngine on
    RewriteCond% (HTTP_HOST) ^ www.site.ru
    RewriteRule ^ (. *) $ Http://site.ru/$1

    # Склеювання дублів сторінок

    RewriteCond% (THE_REQUEST) ^ (3,9) /index.php HTTP /
    RewriteRule ^ index.php $ http: // ваш сайт.ru /

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

    Як заборонити індексацію певних сторінок?

    Дозволи та заборони на індексацію беруться усіма пошуковими системамиз файлу robots.txt, Що знаходиться в кореневому каталозі сервера. Заборона на індексацію ряду сторінок може з'явитися, наприклад, з міркувань таємності або з бажання не індексувати однакові документи в різних кодуваннях. Чим менше ваш сервер, тим швидше робот його обійде. Тому забороните в файлі robots.txt всі документи, які не має сенсу індексувати (наприклад, файли статистики або списки файлів в директоріях). Зверніть особливу увагу на CGI або ISAPI скрипти - наш робот індексує їх нарівні з іншими документами.

    У найпростішому вигляді (дозволено все, крім директорії скриптів) файл robots.txt виглядає наступним чином:

    User-Agent: *
    Disallow: / cgi-bin /

    Детальний опис специфікації файлу можна прочитати на сторінці: «».

    При написанні robots.txt зверніть увагу на наступні часто зустрічаються помилки:

    1. Рядок з полем User-Agent є обов'язковою і повинна передувати рядкам з полем Disallow. Так, наведений нижче файл robots.txt не забороняє нічого:

    Disallow: / cgi-bin
    Disallow: / forum

    2. Порожні рядки в файлі robots.txt є значущими, вони поділяють записи, що відносяться до різних роботам. Наприклад, в наступному фрагменті файлу robots.txt рядок Disallow: / forumігнорується, оскільки перед нею немає рядка з полем User-Agent.

    User-Agent: *
    Disallow: / cgi-bin
    Disallow: / forum

    3. Рядок з полем Disallowможе заборонити індексування документів тільки з одним префіксом. Для заборони декількох префіксів потрібно написати кілька рядків. Наприклад, нижченаведений файл забороняє індексування документів, що починаються з " / Cgi-bin / forum", Яких, швидше за все, не існує (а не документів з префіксами / Cgi-binі / forum).

    User-Agent: *
    Disallow: / cgi-bin / forum

    4. У рядках з полем Disallowзаписуються абсолютні, а відносні префікси. Тобто файл

    User-Agent: *
    Disallow: www.myhost.ru/cgi-bin

    забороняє, наприклад, індексування документа http://www.myhost.ru/www.myhost.ru/cgi-bin/counter.cgi, Але НЕ забороняє індексування документа http://www.myhost.ru/cgi-bin/counter.cgi.

    5. У рядках з полем Disallowвказуються саме префікси, а не що-небудь ще. Так, файл:

    User-Agent: *
    Disallow: *

    забороняє індексування документів, що починаються з символу «*» (яких в природі не існує), і сильно відрізняється від файлу:

    User-Agent: *
    Disallow: /

    який забороняє індексування всього сайту.

    Якщо ви не можете створити / змінити файл robots.txt, То ще не все втрачено - досить додати додатковий тег в HTML-код вашої сторінки (всередині тега ):

    тоді даний документтакож не проіндексований.

    Ви також можете використовувати тег

    Він означає, що робот пошукової машини не повинен йти по посиланнях з даної сторінки.

    Для одночасного заборони індексування сторінки і обходу посилань з неї використовується тег

    Як заборонити індексацію певних частин тексту?

    Щоб заборонити індексування певних фрагментів тексту в документі, позначте їх тегами

    Увага! Тег NOINDEX не повинен порушувати вкладеність інших тегів. Якщо вказати наступну помилкову конструкцію:


    ... код1 ...


    ... код2 ...

    ... код3 ...

    заборона на індексування буде включати не тільки «код1» і «код2», а й «код3».

    Як вибрати головний віртуальний хост з декількох дзеркал?

    Якщо ваш сайт знаходиться на одному сервері (одному IP), але видно в зовнішньому світі під різними іменами (дзеркала, різні віртуальні хости), Яндекс рекомендує вам вибрати те ім'я, під яким ви хочете бути проіндексовані. В іншому випадку Яндекс вибере головне дзеркало самостійно, а інші імена будуть заборонені до індексації.

    Для того, щоб індексувалося вибране вами дзеркало, досить заборонити індексацію всіх інших дзеркал за допомогою. Це можна зробити, використовуючи нестандартне розширення robots.txt - директиву Host, Як її параметр вказавши ім'я основного дзеркала. якщо www.glavnoye-zerkalo.ru- основне дзеркало, то robots.txt повинен виглядати приблизно так:

    User-Agent: *
    Disallow: / forum
    Disallow: / cgi-bin
    Host: www.glavnoye-zerkalo.ru

    З метою сумісності з роботами, які не повністю дотримуються стандарту при обробці robots.txt, директиву Host необхідно додавати в групі, що починається з записи User-Agent, безпосередньо після записів Disallow.

    аргументом директиви Hostє доменне ім'я з номером порту ( 80 за замовчуванням), відокремленим двокрапкою. Якщо який-небудь сайт не вказано як аргумент для Host, Для нього мається на увазі наявність директиви Disallow: /, Тобто повна заборона індексації (при наявності в групі хоча б однієї коректної директиви Host). Таким чином, файли robots.txtвиду

    User-Agent: *
    Host: www.myhost.ru

    User-Agent: *
    Host: www.myhost.ru:80

    еквівалентні і забороняють індексування як www.otherhost.ru, так і www.myhost.ru:8080.

    Параметр директиви Host зобов'язаний складатися з одного коректного імені хоста (тобто відповідного RFC 952і яка не є IP-адресою) і допустимого номера порту. Некоректно складені рядки Hostігноруються.

    # Приклади ігнорованих директив Host
    Host: www.myhost- .ru
    Host: www.- myhost.ru
    Host: www.myhost.ru:0
    Host: www.my_ host.ru
    Host:. my-host.ru:8000
    Host: my-host.ru.
    Host: my .. host.ru
    Host: www.myhost.ru/
    Host: www.myhost.ru:8080/
    Host: http: // www.myhost.ru
    Host: www.mysi.te
    Host: 213.180.194.129
    Host: www.firsthost.ru, www.secondhost.ru
    Host: www.firsthost.ru www.secondhost.ru

    Якщо у вас сервер Apache, То можна замість використання директиви Host задати robots.txt з використанням директив SSI:


    User-Agent: *
    Disallow: /

    У цьому файлі роботу заборонений обхід всіх хостів, крім www.главное_імя.ru

    Як включати SSI, можна прочитати в документації по вашого сервера або звернутися до вашого системному адміністратору. Перевірити результат можна, просто надіславши запит сторінки:

    Http: //www.главное_імя.ru/robots.txt
    http: //www.другое_імя.ru/robots.txtі т.д. Результати повинні бути різні.

    Рекомендації для веб-сервера Русский Apache

    В robots.txt на сайтах з російським Апачем повинні бути заборонені для роботів все кодування, крім основної.

    Якщо кодування розкладені по портам (або серверів), то треба видавати на різних портах (серверах) РІЗНИЙ robots.txt. А саме, у всіх файлах robots.txt для всіх портів / серверів, крім «основного», має бути написано:

    User-Agent: *
    Disallow: /

    Для цього можна використовувати механізм SSI,.

    Якщо кодування в вашому Apache виділяються по іменах «віртуальних» директорій, то треба написати один robots.txt, в якому повинні бути приблизно такі рядки (в залежності від назв директорій):

    User-Agent: *
    Disallow: / dos
    Disallow: / mac
    Disallow: / koi