Просуваємо бізнес-сайти

3216
  • URL адреси і дзеркала — їх вплив на успіх просування
  • Звідки виникають дзеркала зі слешем і з index.php
  • Причина появи дзеркал з WWW і чому це небезпечно
  • Як перевірити дзеркала вашого сайту?
  • Як склеїти знайдені дзеркала?
  • Управління сервером Apache з допомогою .htaccess
  • Як склеїти дзеркала при використанні сервера Apache
  • Canonical для видалення дублів вмісту
  • Директива Disallow в robots.txt
  • Здрастуйте, шановні читачі блогу . Продовжуємо тему просування сайтів методами SEO оптимізації, розпочату в статті про аудит юзабіліті сайту. Трохи раніше ми розглянули всі способи просування комерційних сайтів і в загальних рисах познайомилися з роботою пошукових систем. Сьогодні у нас на порядку денному питання взаємодії пошукових систем та веб-сайту.

    Просуваємо бізнес-сайти

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

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

    URL адреси і дзеркала — їх вплив на успіх просування

    Що таке URL-адреси я вже досить детально розписував, але щоб не змушувати вас постійно переходити з однієї статті в іншу, тут я частково повторюся. Урл представляє з себе адреса веб-сторінки (документа) у мережі інтернет. Записується він у певному форматі, доступному розумінню DNS (серверів доменних імен).

    Якщо брати вихідну схему формування Урл адреси, то виглядає вона моторошно:

    Схема формирования URL адресаПросуваємо бізнес-сайти

    Однак, логін і пароль при зверненні до вебстраницам використовується, напевно, вкрай рідко (це більше властиве схемою або FTP). Тому простіше буде розглянути реальний приклад Url:

    https:///papka/failik.html

    В даному випадку це адреса не існує на моєму блозі сторінки з назвою файлу failik.html (цей файлик може фізично знаходитися на моєму сервері в папці papka, або він може на льоту генеруватися CMS при запиті цієї сторінки — читайте про принципи роботи CMS).

    Все, що в URL написано після третього слеша зліва (включаючи і його теж — /papka/failik.html), є відносним (внутрішнім) адресу місцезнаходження документа (щодо кореневої папки сервера). Більш детально про абсолютні та відносні адреси читайте за наведеним посиланням. Папки, так само як і файли, які можуть існувати фізично на сервері, а можуть бути і віртуальними (їх генерує CMS, маючи на увазі під папками розділи і категорії — читайте про ЧПУ в WordPress і SEF в Joomla).

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

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

    Протокол визначає спосіб взаємодії браузера (або іншої програми-клієнта, наприклад, FTP менеджера Файлзилла) і сервера, на якому розташований сайт. Варіантів протоколів досить багато, але найчастіше використовується саме показаний в прикладі HTTP — протокол передачі гіпертексту). Іноді ви можете зустріти і HTTPS, що означає шифрування переданих даних.

    Звідки виникають дзеркала зі слешем і без слеша на кінці і з index.php

    Ще дуже важливо розуміти, що в інтернеті все побудовано на принципах, закладених в Лінукс системах, якими потрібно керуватися при написанні і читанні Url адрес. Наприклад, такий запис:

    https:///papka

    буде означати, що йде звернення до файлу papka (в лінуксі розширення для файлів не потрібні, на відміну від Віндовс), а ось такий вид запису (зі слешем на кінці):

    https:///papka/

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

    В лінуксі papka.html — це не файл з розширенням Html, а просто таке дивне ім’я файлика з крапкою посередині. Тому і ви, наприклад, при настройці ЧПУ (трохи вище наводив посилання) можете додавати закінчення .html або .php (або будь-яке інше) в кінці Урлов сторінок свого сайту, а можете і не додавати. Нікого значення це не має, а лише створює якесь відчуття закінченості для користувачів, які звикли до традиційної ОС Windows.

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

    https:///papka

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

    Однак, відкрити користувачеві просто вміст папки сервер не може (точніше може, але не повинен цього робити, бо тим самим підриває безпеку сайту — для цього навіть спеціальну директиву «заборони лістингу каталогу» в кореневій файл .htaccess додають на окремому рядку: Options -Indexes), бо в папці контент, по ідеї, утримуватися не повинен.

    Сервер у цьому випадку повинен вивчити назви файлів, укладених в цій папці на предмет знаходження чого-небудь з назвою index, і саме його відкрити при запиті такого Url адреси, що вказує на папку. Це може бути index.html або index.php.

    Така ситуація призводить до так званого «дублювання», коли одна і та ж сторінка доступна за трьома різними Url адресами, які будуть називатися дзеркалами. У нашому прикладі це будуть адреси:

    https:///papka
    https:///papka/
    https:///papka/index.php

    Чи добре це? Немає, і цю проблему в обов’язковому порядку потрібно вирішувати. Справа в тому, що у пошукових машин обмежений ресурс (технічний та матеріальний), а значить, виявивши одну і ту ж інформацію за трьома різними адресами, машина не буде зберігати всі три Урла і разом з ними три однакові сторінки в індексному базі. Вона змушена буде вибрати тільки один з них для обліку і зберігання. А який саме?

    Цього ніхто вгадати не в змозі. Але один з Урлов стане головним, а інші будуть визнані дзеркалам. Дзеркала машина вважатиме синонімами (алиасами) і склеїть їх. Вся проблема в тому, що дуже складно вгадати, який саме варіант написання Урла стане головним і потрапить в індекс. А значить не зрозуміло, яку саме сторінку нам потрібно просувати, як SEO оптимізаторів (на який Урл закуповувати посилання або робити внутрішню перелінковку).

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

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

    Причина появи дзеркал з WWW у назві доменів і чому це небезпечно

    Це ті самі дзеркала з WWW і без нього, про виникнення і боротьбі з якими мені вже доводилося писати. Однак, повторюся. Виглядають дзеркала з WWW і без оних приблизно так:

    https://www./papka/fail.html
    https:///papka/fail.html

    Звідки взялося це горезвісне WWW? У статті про DNS і структуру доменних імен я писав, що система доменних імен з’явилася не одразу, а вже на одному з етапів існування і розвитку інтернету. До неї адреси ресурсів тоді ще не глобальній мережі виглядали якось так: www.ktonanovenkogo або www.magazin.

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

    …третий_уровень.второй_уровень.первый_уровень.нулевая_зона

    Доменні зони стали розділяти крапкою. Причому відлік ведеться справа наліво. Нульова зона, по ідеї, повинна була позначатися лише точкою, але в силу того, що це було однаково для всіх — від зайвого знака в самому кінці доменного імені вирішили відмовитися. Домени першого рівня розділили на два типи — призначені для країн (ru, ua і т. д.) і загальнодоступні (com, net тощо).

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

    Після введення в дію DNS серверів постало питання про перехід зі старих систем позначення сайтів до нових. Вирішили зробити просто перенесли структуру цілком і поставили www.ktonanovenkogo або www.magazin відразу перед доменною зоною першого рівня. Вийшло щось типу www. або www.magazin.com.

    Тобто WWW стало автоматично доменом третього рівня (субдоменом) і на перших порах всі DNS сервера містили такі конструкції — всі хости сайтів того часу починалися з WWW. Сенсу в цьому, проте, ніякого не було, але зіграла свою роль все та ж звичка, що змушує нас додавати до Урлам сторінок розширення html або php.

    WWW — це рудимент (штучне впровадження), який дістався нам з давньої історії того, що таке інтернет, і який в деякому роді є перешкодою. Кожному вебмастеру надається можливість самому боротися з цим злом, ламаючи мозок з приводу якоїсь «розумна людина» все це придумав.

    Виходить, що у кожного домена другого рівня (отриманого у реєстратора) існує аліас (дзеркало) на домені третього рівня (з WWW). Цей подарунок ви отримуєте безпосередньо від реєстратора, який робить для вашого домену аліас з WWW. Це реалізується з міркувань зручності, щоб «чайники», які вважають, що всі веб адреси повинні починатися з трьох чарівних літер, не були б розчаровані в своїх помилках, додавши їх в Урл вашого сайту.

    Дана ситуація (укупі з описаною вище ситуацією зі слешем в кінці Url адреси і закінченням index.php знову ж буде трактуватися пошуковими системами не передбачено (не можна вгадати, яке дзеркало пошуковик вважатиме головним, надай ви йому можливість вибирати). Це загрожує втратою частини посилальної маси, тому з такими мимовільними дзеркалами треба розбиратися і боротися.

    Немає правильного або неправильного дзеркала (з WWW або без нього). Для SEO головне, щоб це дзеркало було одне.

    Як перевірити і склеїти дзеркала вашого сайту?

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

    url: | url:www.

    В результаті ви побачите те що ніколи не бачили видачу Яндекса за цим запитом, де може бути кілька варіантів:

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

    Какое зеркало сайта выбрал Яндекс - с WWW или без негоПросуваємо бізнес-сайти

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

  • У видачі виявилося два результату — означає, що в індексі зберігаються обидва дзеркала вашого сайту. Процес визначення головного дзеркала пошукачем ще не був завершений, або робот-дзеркальник ще не відвідав ваш сайт, щоб склеїти їх потрібним чином.
  • У видачі за даним запитом багато результатів — означає, що ви помилилися у використанні операторів мови запитів Яндекса, наведених вище. Перевір правильність їх.
  • У видачі немає взагалі результатів за даним запитом — означає, що ваш сайт ще не був проіндексований даними пошукачем.
  • Точно так само ви можете перевірити і наявність в індексі дзеркал основного хоста з і без слеша на кінці або з index.php:

    url: | url:/index.php

    Це був спосіб, коли ми запитували про наявність дзеркал в індексі у тієї самої інстанції, заради якої ми і намагаємося — пошукової системи. Однак, можна і прямо на своєму сайті перевірити склейку дзеркал.

    Просто введіть в адресний рядок браузера спочатку Урл будь-якої сторінки WWW, а потім без цієї комбінації. Якщо в одному з випадків перейде на автоматичне зміна введеного вами Url (зникне WWW або, навпаки, з’явиться), то значить у вас на сайті все гаразд зі склейкою дзеркал з використання 301 редіректу.

    Проверка кода ответа сервера в Яндекс ВебмастереПросуваємо бізнес-сайти

    Трохи нижче я буду говорити про коди відповіді сервера. Так от, якщо ми подивимося відповідь мого сервера на Урл з WWW, то як раз і побачимо використання 301 редіректу (для цього я взяв сервіс Яндекса «Перевірка відповіді сервера»). Той же 301 редирект буде показаний і при введенні в цей сервіс Урла «https:///index.php».

    Як склеїти знайдені дзеркала?

    Інше питання — як склеїти ці самі дзеркала, якщо ви виявили їх наявність в індексі пошуковиків? В принципі, у статті про 301 редирект для склеювання дзеркал з WWW я наводив один із варіантів реалізації. Однак, все залежить від того програмного забезпечення, на якому працює ваш сервер. У кого-то це спрацює, а у кого-то немає. Що робити?

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

    Крім цього, для Яндекса можна використовувати директиву Host у файлі robots.txt (вказавши в ній основне дзеркало), про який я вже досить докладно писав. Також можна використовувати панель Яндекс Вебмастера для вказівки основного дзеркала (вкладка «Налаштування індексування» — «Переїзд сайту»):

    Настройка главного зеркала в Яндекс ВебмастереПросуваємо бізнес-сайти

    У мене був відразу після створення блогу налаштований 301 редирект на Урл адреси без WWW, а також прописана директива в роботс. тхт (у блоці, призначеному для Яндекса — User-agent: Yandex):

    User-agent: *
    Disallow:
    User-agent: Yandex
    Disallow:
    Host:
    Sitemap: https:///sitemap.xml.gz
    Sitemap: https:///sitemap.xml

    Сенсу ставити головне дзеркало у налаштуваннях Вебмастера вже не було, бо Яндекс і так правильно вибрав головне дзеркало.

    Управління сервером Apache з допомогою .htaccess

    З високою ймовірністю ваш сайт буде працювати під управлінням веб-сервера Apache (він використовується на переважній числі серверів). Він безкоштовний, постійно оновлюваний, добре оттестировать і має велику кількість розширень. Давайте подивимося, як з допомогою налаштувань його конфігураційного файлу можна склеїти обидва типу описаних вище дзеркал (з WWW і і index.php).

    У веб-сервера Apache основний конфігураційний файл називається httpd.conf. Однак, якщо в ньому прописана роздільна директива, то для кожного каталогу сайту на вашому сервері можна буде використовувати додатковий файл конфігурації .htaccess. Можливості у нього такі ж, як і у httpd.conf, але всі прописані в ньому директиви будуть застосовуватись тільки до тієї папки, у якій він знаходиться.

    Однак, якщо додайте файл .htaccess в корені, то його дія пошириться на весь ваш сайт. Цей спосіб конфігурації Apache зручний тим, що доступ до .htaccess, що лежить в корені сайту, можна отримати по звичайному ФТП з’єднанню з допомогою будь-якого ФТП клієнта. Редагувати ж його можна в будь-якому текстовому або Html редакторі (в тому числі і в онлайн редакторі).

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

    Однак, настійно рекомендую перед кожною правкою .htaccess зберігати його до себе на комп’ютер, бо з-за помилки у вноситься інструкції може стати недоступним весь сайт. Маючи бекап, ви зможете відновити все як було в лічені секунди. Ну і також раджу виправлення вносити не в звичайному блокноті Віндовс, а в редакторі на кшталт Notepad++, де є можливість відкотитися назад.

    Як склеїти дзеркала при використанні сервера Apache

    Отже, більшість сайтів в рунеті працюють на Apache, тому буде не зайвим навести код, що додається в .htaccess, який гарантує стовідсоткову склейку описаних вище дзеркал. У своїй основі він спирається на 301 редирект з усіх Url адрес, що мають у своєму складі WWW на Урли без WWW (або навпаки). Що таке 301 редирект?

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

    Якщо ж говорити коротко, то код відповіді 301 означає «переадресацію назавжди», після якої пошукова система виключить зі своєї бази старий Урл, а всі посилання, що на нього вели, будуть зараховані Урлу новому (здійсниться перенесення посилального ваги). На вашому ж сайті при запиті сторінки за старим урлу буде відбуватися миттєвий автоматичний (не помітний) перекидання на новий. Як це реалізувати?

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

    Отже, давайте зробимо 301 редирект з WWW без WWW (з усіх урлов, що включають WWW, на урли без цих трьох літер). Для цього достатньо буде в файл .htaccess додати конструкцію з чотирьох рядків (скопіюйте попередньо оригінальний файл .htaccess до себе на комп’ютер, щоб можна було б їм замінити наявний на сервері у випадку невдачі):

    Options +FollowSymLinks
    RewriteEngine On
    RewriteCond %{HTTP_HOST} ^www\.(.*) [NC]
    RewriteRule ^(.*)$ http://%1/$1 [R=301,L]

    Перші дві строчки роблять щось таке, що я толком пояснити не можу, тому і не буду. Ну, а дві останні якраз і здійснюють перенаправлення на Урли без WWW. Всякі хитрі значки, використовувані в цих рядках, відносяться до синтаксису так званих «регулярних виразів», які допомагають програмістам в їх нелегкому завданні. Хочете дізнатися більше про регулярні вирази — велком в Вікіпедію (і побільше терпіння з собою візьміть).

    Є ще один популярний варіант реалізації того ж самого дійства (редіректу з Урлов, використовують WWW):

    Options +FollowSymLinks
    RewriteEngine On
    RewriteCond %{HTTP_HOST} ^www.domain\.ru$ [NC]
    RewriteRule ^(.*)$ http://domain.ru/$1 [R=301,L]

    Тільки не забудьте замінити domain і domain.ru на назва вашого домену, наприклад, ktonanovenkogo і

    Якщо ви хочете, що у ваших урлах рудимент у вигляді WWW все ж залишався, то зробіть зворотний 301 редирект з Урлов без WWW на Урли з WWW:

    Options +FollowSymLinks
    RewriteEngine On
    RewriteCond %{HTTP_HOST} ^www.domain\.ru$ [NC]
    RewriteRule ^(.*)$ http://domain.ru/$1 [R=301,L]

    Ну, і альтернативний варіант для гурманів:

    Options +FollowSymLinks
    RewriteEngine On
    RewriteCond %{HTTP_HOST} !^www\.(.*) [NC]
    RewriteRule ^(.*)$ http://www.%1/$1 [R=301,L]

    З приводу склеювання дзеркал зі слешем, без нього і з index.php (або index.html — залежить від налаштування веб-сервера) нічого певного сказати не можу, бо у мене хостер цю проблему вирішував. Раджу вам зробити найпростішу перевірку і подивитися що відбувається, коли в адресний рядок браузера ви вводите:

    https://
    https:///
    https:///papka/index.php
    https:///papka/index.html

    Особисто у мене в перших трьох випадках Url в адресному рядку автоматично замінюється на перший варіант, а в останньому видає 404 помилку (документ не знайдений). Тобто виходить, що у мене ці дзеркала успішно склеєні, а сторінка з index.html просто відзначена, як не існує сторінка, що теж вірно.

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

    Canonical для видалення дублів вмісту

    Хоча стаття і так вже вийшла надмірно довгою, не можу не згадати про таку чудову річ, як атрибут rel=»canonical» тега службової гіперпосилання link. Він дозволяє на всіх сторінках-дублях (включаючи і описані вище дзеркала) прописати адресу канонічного Урла, який і призначений для зберігання в індексному базі пошуковика.

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

    Крім описаних вище дзеркал дублі сторінок можуть плодити і самі движки сайтів. Також в деяких движки, при знаходженні товару або статті у кількох категоріях, у них будуть формувати різні Урли (з різним назвою категорії всередині Url). Ну і все ті ж Урли з параметрами, які можуть виглядати, наприклад, так:

    https:///category/joomla/joomla-2-5-3-x?print=yes

    Однак, якщо ваш двигун буде прописувати між тегами Head тег link rel=»canonical» з вказання Url основної сторінки, яка і повинна бути проіндексована пошуковими системами, то ви уникнете непотрібних проблем. Наприклад, на моєму блозі для показаної вище сторінки її вихідний код буде містити ось таку конструкцію:

    Прописываем canonical для удаления дублей страницПросуваємо бізнес-сайти

    Якщо говорити про WordPress, то я для додавання Canonical на всіх сторінках блогу, використовую плагін All in One SEO Pack. Можливо, я відстав від життя і в цей движок вже інтегрована підтримка Canonical. Якісь механізми мають підтримку цієї функції за замовчуванням, а в які-то потрібно буде встановлювати розширення.

    Однак, пошуковим роботом Яндекса атрибут rel=»canonical» не сто відсотків буде врахований. Canonical для нього носить рекомендаційний, а не обов’язковий характер, тому склеивайте дзеркала з допомогою редиректів — так буде спокійніше.

    Директива Disallow в robots.txt

    Теж дуже відомий спосіб боротьби з дублями контенту, який з’явився ще до введення rel=»canonical». Є такий чудовий інструмент для спілкування з пошуковим роботом, як файлик з промовистою назвою — robots.txt. Про оптимальний robots.txt lzk WordPress, Joomla та SMF я вже писав, але підкреслю, що там ми активно використовували директиви Disallow, що дозволяють відмовити робота пошуковий системи від індексації чого б то не було.

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

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