Проверить склейку сайта

Что такое зеркала?

Прежде чем начать нашу статью о склейке, давайте ближе познакомимся с термином «зеркало».

Зеркало — это доменное имя, по которому доступна полная или частичная копия сайта. Предположим, что у нас есть основной домен dh-agency.ru. Тогда www.dh-agency.ru будет для него зеркалом, так как по этому адресу доступна полная копия сайта.

Визуально зеркала можно представить в виде нескольких адресов, которые ведут на один и тот же сайт.

Зеркалами могут быть не только различные варианты написания одного и того же домена, но и совершенно разные адреса. К примеру, если мы привяжем к нашему сайту доменное имя digitalhedgehogs.ru, оно также станет зеркалом, поскольку будет вести на тот же ресурс, что и dh-agency.ru.

Что такое склейка доменов (зеркал)?

Склейка доменов (зеркал) — это объединение нескольких доменных имен ведущих на один и тот же сайт в условную группу с последующим выбором основного.

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

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

Срок склейки доменов

Сроки склейки доменов (зеркал) будут зависеть от того, что именно Вы хотите склеить. Если речь идет о доменных именах с www и без www, то потребуется всего 1-2 обновления поисковой базы. Во временном периоде это будет около 10-14 дней.

Если необходимо склеить два разных доменных имени, то времени потребуется куда больше. Стандартный срок для разноименных доменов — 2-7 недель.

На расклейку и переклейку время уйдет столько же. Не нужно думать, что зеркала возможно расклеить за один день, это не так.

Что значит склеенный домен (зеркало)?

Если доменные имена (зеркала) склеены, это означает, что:

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

Как склеить домены (зеркала)?

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

Весь процесс происходит в несколько этапов.

А теперь подробнее о каждом шаге.

Выбор основного зеркала

Необходимо со всей серьезностью отнестись к выбору главного зеркала сайта, ведь именно ему будет передан «вес» и оно будет отображаться в поисковой выдаче. Главное зеркало должно соответствовать следующим требованиям:

Количество раз, которое Вы можете выставлять главное зеркало, неограниченно. Однако мы настоятельно рекомендуем сделать это единожды, навсегда.

Создание постоянной переадресации

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

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

О том, как это делается технически, мы говорили в одной из наших предыдущих статей.

Настройка главного зеркала в Вебмастере

После того, как переадресация была настроена, необходимо указать Яндексу на главное зеркало. Делается это в Вебмастере — webmaster.yandex.ru. Несмотря на то, что после 301 редиректа, поисковые системы уже смогут сделать верный выбор, данный шаг пропускать не нужно.

Далее выбираем необходимый домен или ставим галочки напротив «Добавить HTTPS»/ «Добавить WWW» в соответствии с выбранным ранее главным зеркалом.

Жмем кнопку «Сохранить». Вот и все, Яндекс оповещен о выборе главного зеркала.

Создание директивы host в robots. txt

Теперь прописываем главное зеркало напротив директивы «Host:». Обратите внимание, если Вы имеете протокол http://, то в данной директиве писать его не нужно.

Настройка CMS

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

Склеиваем домены с www и без www

Самый простой вариант склейки зеркал, это склейка доменов с www и без www. Никаких сложностей тут нету, необходимо выполнить несколько шагов.

Вот и весь процесс. Склейка доменов с www и без www, обычно, происходит за 1-2 недели и редко вызывает проблемы.

Как убрать склейку доменов?

Чтобы убрать склейку доменов, необходимо проделать несколько простых шагов.

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

Как проверить склейку сайтов?

В одной из статей я уже рассказывал про склейку сайтов, а в данной заметке опишу 2 простых способа, как вообще её проверять.

Кстати, а зачем это нужно делать? Пусть, например, имеются два веб-проекта с адресами site.ru и www.site.ru — что здесь такого?

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

Если вы уже:

но всё равно вас беспокоит, всё ли прошло хорошо (склеилось ли), то можно самостоятельно проверить склейку сайтов.

Проверка в Яндексе

Заходим сюда: http://help.yandex.ru/catalogue/?id=1111360 и вводим два адреса (например, с WWW и без WWW):

Проверка Тиц в Яндекс

Если для адресов с WWW и без WWW показатели ТИЦ будут отличаться, то значит Яндекс считает два этих адреса принадлежащими к разным доменам, а это плохо и надо поискать ошибку. Возможно, не указана директива Host в Robots.txt и не сделан 301-й редирект.

Проверка склейки сайтов в Google

Здесь всё можно сделать при помощи такого запроса , например:

Проверка склейки в Google

На скриншоте видно, что для ресурса Ya.ru главным зеркалом является адрес WWW.ya.ru. А, например, для моего сайта, наоборот, главным зеркалом является Web.ru.net, а не www. Web-ru.net.

Если же при запросах будут выдаваться результаты — это плохо.

Как видите, проверять склейку сайтов не так уж и сложно. Если вас беспокоит, что что-то склеилось не так, как вы ожидали — пользуйтесь этими инструментами!

Сервисы проверки склейки доменов

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

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

Стоимость сервиса

Для тарифного плана StartUp представлены дополнительные возможности — оплата предусмотрена ежемесячно, на 3 месяца и на год. По годовой предоплате действует скидка — стоимость услуги составляет 119 рублей в месяц.

Тарифы сервиса

Здравствуйте, уважаемые читатели блога KtoNaNovenkogo.ru. Продолжаем тему продвижения сайтов методами SEO оптимизации, начатую в статье про аудит юзабилити сайта. Чуть раньше мы рассмотрели все способы продвижения коммерческих сайтов и в общих чертах познакомились с работой поисковых систем. Сегодня у нас на повестке дня вопрос взаимодействия поисковых систем и сайта.

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

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

P. S. Как бы я не хотел, но всего необходимого в одну (или даже несколько публикаций) не впихнешь (а дьявол, как говорится, кроется в деталях). В общем, есть вариант пройти онлайн-обучение по теме «SEO 2.0 от TexTerra«. Все же, за это время рассказать можно, наверное, все. Но это платно, само собой.

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

Что такое URL адреса я уже довольно подробно расписывал, но чтобы не заставлять вас постоянно переходить из одной статьи в другую, здесь я частично повторюсь. Урл представляет из себя адрес вебстраницы (документа) в сети интернет. Записывается он в определенном формате, доступном пониманию DNS (серверам доменных имен).

Если брать исходную схему формирования Урл адреса, то выглядит она пугающе:

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

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

Для простоты предположим, что в нашем примере имеется физический файлик и физическая папка papka, которая в свою очередь находится в корневой директории сайта. Однако, не понятно, как DNS сервера смогут понять, на каком именно из многих миллионов серверов искать данный файлик и папку. Тут как раз важна та часть URL адреса, которая содержит в себе название хоста (что это такое?). Она заключена между вторым и третьим слешем слева и в моем случае представляет из себя „ktonanovenkogo.ru“.

Кстати, возможны еще варианты, когда название хоста и домена не совпадут. Например, если бы у меня главное зеркало было бы выбрано как „www.ktonanovenkogo.ru“, то это было бы названием хоста, в то время как домен по-прежнему был бы — ktonanovenkogo.ru. Но это нюансы. Вернувшись к Урл адресу, мы еще отметим, что буковки, стоящие перед двойным слешем, являют собой обозначение схемы или, другими словами, протокола, по которому должно осуществляться подключение.

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

Откуда возникают зеркала со слешем и без слеша на конце и с index. php

Еще очень важно понимать, что в интернете все построено на принципах, заложенных в Линукс системах, которыми и нужно руководствоваться при написании и прочтении Урл адресов. Например, подобная запись:

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

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

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

Именно поэтому при написании и понимании Урлов следует обращать внимание на завершающий слеш. Если он есть, то обращение идет к папке, а если нет — то к файлу. Все просто. Однако, это мы с вами знаем эту тонкую разницу, а подавляющее большинство пользователей сети не знают. Поэтому все веб-серверы настроены таким образом, что при обращении к ним по следующему Урлу:

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

Однако, открыть пользователю просто содержимое папки сервер не может (точнее может, но не должен этого делать, ибо тем самым подрывает безопасность сайта — для этого даже специальную директиву „запрета листинга каталога“ в корневой файл .htaccess добавляют на отдельной строке: Options -Indexes), ибо в папке контент, по идее, содержаться не должен.

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

Такая сложившаяся ситуация приводит к так называемому „дублированию“, когда одна и та же страница доступна по трем разным Урл адресам, которые будут называться зеркалами. В нашем примере это будут адреса:

Хорошо ли это? Нет, и эту проблему в обязательном порядке нужно решать. Дело в том, что у поисковых машин ограничен ресурс (технический и материальный), а значит, обнаружив одну и ту же информацию по трем разным адресам, машина не будет хранить все три Урла и вместе с ними три одинаковые страницы в индексной базе. Она вынуждена будет выбрать только один из них для учета и хранения. А какой именно?

Этого никто угадать не в состоянии. Но один из Урлов станет главным, а остальные будут признаны зеркалам. Зеркала машина посчитает синонимами (алиасами) и склеит их. Вся проблема в том, что очень сложно угадать, какой именно вариант написания Урла станет главным и попадет в индекс. А значит не понятно, какую именно страницу нам нужно продвигать, как SEO оптимизаторам (на какой Урл закупать ссылки или делать внутреннюю перелинковку).

Если ваше мнение по выбору главного зеркала не совпадет с мнением поисковой системы, то затраченные на продвижение усилия и средства будут напрасными. В принципе, для каждой страницы сайта можно спустя какое-то время понять, какой же вариант поисковик сохранил в индексной базе, но этот путь уж слишком сложен. Гораздо более простым будет способ, при котором поисковому роботу мы не предоставим возможности выбирать (дать только один вариант). Как это сделать?

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

Причина появления зеркал с WWW в названии доменов и почему это опасно

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

Откуда взялось это пресловутое WWW? В статье про DNS и структуру доменных имен я писал, что система доменных имен появилась не сразу, а уже на одном из этапов существования и развития интернета. До нее адреса ресурсов тогда еще не глобальной сети выглядели как-то так: www.ktonanovenkogo или www.magazin.

Возможно, что я не точно передаю картину, но проверить сейчас это уже довольно-таки хлопотно, да и не нужно. Оставим на суд зрителей. Итак, после появления идеи DNS все доменные имена стали формироваться уже по другому принципу:

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

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

После ввода в строй DNS серверов встал вопрос о переходе со старых систем обозначения сайтов к новым. Решили сделать просто — перенесли структуру целиком и поставили www.ktonanovenkogo или www.magazin сразу перед доменной зоной первого уровня. Получилось что-то типа www.ktonanovenkogo.ru или www.magazin.com.

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

WWW — это рудимент (искусственное внедрение), доставшийся нам из давней истории того, что такое интернет, и который в некотором роде является помехой. Каждому вебмастеру предоставляется возможность самому бороться с этим злом, ломая мозг по поводу — какой „умный человек“ все это придумал.

Получается, что у каждого домена второго уровня (полученного у регистратора) существует алиас (зеркало) на домене третьего уровня (с WWW). Этот подарок вы получаете непосредственно от регистратора, который делает для вашего домена алиас с WWW. Это реализуется из соображений удобства, чтобы „чайники“, считающие, что все веб адреса должны начинаться с трех волшебных буковок, не были бы разочарованы в своих заблуждениях, добавив их в Урл вашего сайта.

Данная ситуация (вкупе с описанной выше ситуацией со слешем в конце Урл адреса и окончанием index.php) опять же будет трактоваться поисковыми системами не предсказуемо (нельзя угадать, какое зеркало поисковик посчитает главным, предоставь вы ему возможность выбирать). Это чревато потерей части ссылочной массы, поэтому с такими невольными зеркалами надо разбираться и бороться.

Нет правильного или неправильного зеркала (с WWW или без него). Для SEO главное, чтобы это зеркало было одно.

Как проверить и склеить зеркала вашего сайта?

Если помните, то я как-то писал про язык запросов Яндекса, который призван помогать быстрее найти нужный ответ, например, путем сужения области поиска. Вот мы им и воспользуемся, чтобы ответить на волнующий нас вопрос. Для этого в поисковую строку Яндекса нужно будет ввести следующую конструкцию:

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

Точно так же вы можете проверить и наличие в индексе зеркал основного хоста с и без слеша на конце или с index.php:

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

Просто введите в адресную строку браузера сначала Урл любой странички с WWW, а потом без этой комбинации. Если в одном из случаев перейдет автоматическое изменение введенного вами Урла (исчезнет WWW или, наоборот, появится), то значит у вас на сайте все в порядке со склейкой зеркал с использование 301 редиректа.

Чуть ниже я буду говорить про коды ответа сервера. Так вот, если мы посмотрим ответ моего сервера на Урл с WWW, то как раз и увидим использование 301 редиректа (для этого я взял сервис Яндекса „Проверка ответа сервера“). Тот же 301 редирект будет показан и при вводе в этот сервис Урла „https://ktonanovenkogo.ru/index.php“.

Как склеить найденные зеркала?

Другой вопрос — как склеить эти самые зеркала, если вы обнаружили их наличие в индексе поисковиков? В принципе, в статье про 301 редирект для склейки зеркал с WWW я приводил один из вариантов реализации. Однако, все зависит от того программного обеспечения, на котором работает ваш сервер. У кого-то это сработает, а у кого-то нет. Что делать?

Во-первых, не паниковать. Ибо самое важное вы уже сделали — нашли проблему, которая мешала или могла помешать успешному продвижению. Во-вторых, можно просто обратиться в техподдержку вашего хостинга, обстоятельно объяснить возникшую проблему и (бесплатно или за денежку) договориться о том, чтобы вам ее устранили. Для сисадмина хостинга это совсем не сложно.

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

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

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

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

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

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

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

Как склеить зеркала при использовании сервера Apache

Итак, большинство сайтов в рунете работают на Apache, поэтому будет не лишним привести код, добавляемый в .htaccess, который гарантирует стопроцентную склейку описанных выше зеркал. В своей основе он опирается на 301 редирект со всех Урл адресов, имеющих в своем составе WWW на Урлы без WWW (или наоборот). Что такое 301 редирект?

Если же говорить кратко, то код ответа 301 означает „переадресацию навсегда“, после которой поисковая система исключит из своей базы старый Урл, а все ссылки, что на него вели, будут засчитаны Урлу новому (осуществится перенос ссылочного веса). На вашем же сайте при запросе страницы по старому урлу будет происходить автоматический мгновенный (не заметный) переброс на новый. Как это реализовать?

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

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

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

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

Если вы хотите, что в ваших урлах рудимент в виде WWW все же оставался, то сделайте обратный 301 редирект с Урлов без WWW на Урлы с WWW:

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

По поводу склеивания зеркал со слешем, без него и с index.php (или index.html — зависит от настройки веб-сервера) ничего определенного сказать не могу, ибо у меня хостер эту проблему решал. Советую вам сделать простейшую проверку и посмотреть что происходит, когда в адресную строку браузера вы вводите:

Лично у меня в первых трех случаях Урл в адресной строке автоматически заменяется на первый вариант, а в последнем выдает 404 ошибку (документ не найден). Т.е. получается, что у меня эти зеркала успешно склеены, а страница с index.html просто отмечена, как не существующая страница, что тоже верно.

Если у вас в адресной строке после добавления к Урлу главной страницы слеша или index.php открывается главная, но сам Урл не меняется, то имеет место проблема с не склеенными зеркалами. Обращайтесь к хостеру за консультацией или помощью. Повторюсь, что для администратора сервера это не сложная задачка.

Canonical для удаления дублей контента

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

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

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

Однако, если ваш движок будет прописывать между тегами Head тег link rel=»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, позволяющие отговорить робота поисковый системы от индексации чего бы то ни было.