Как убирались дубли контента и ссылок сайта на Битриксе
В инструментах для вебмастеров у Google есть классный механизм для поиска дублей сайта. И даже придуман Атрибут rel=»canonical» тега <link> для устранения дублей.
Так как 5 лет назад мы «допиливали» Битрикс под свои нужды и сваяли жуткого монстра, разумеется, не особо заботясь о мегапозициях в поисковой выдаче. А сейчас я вот несколько месяцев отслаиваю пласты SEO и додумалась, как устранить нам универсальным куском кода все дубли и не допустить их в будущем.
Итак, поиски по форумам Битрикса сообщили, что от дублей спасают три директивы:
Disallow: /*ELEMENT_ID*
Disallow: /*SHOWALL*
Disallow: /*PAGEN*
И очень желательно доработать robots.txt, что и было сделано (пока немножко, в рамках теста), а именно я закрыла лишние страницы с параметрами:
Disallow: /search
Disallow: /*search.php*
Disallow: /*/search
Disallow: /*PAGE_NAME=search
Disallow: /*PAGE_NAME=user_post
Disallow: /*?print=
Disallow: /*&print=
Disallow: /*register=
Disallow: /*forgot_password=
Disallow: /*change_password=
Disallow: /*login=
Disallow: /*logout=
Disallow: /*auth=
Disallow: /*action=ADD_TO_COMPARE_LIST
Disallow: /*action=DELETE_FROM_COMPARE_LIST
Disallow: /*?PAGEN
Disallow: /*?PAGEN_*=
Disallow: /*SHOWALL
Disallow: /*show_all=
Disallow: /?sphrase_id=*
Disallow: /*bitrix_*=
Disallow: /*backurl=*
Disallow: /*BACKURL=*
Disallow: /*back_url=*
Disallow: /*BACK_URL=*
Disallow: /*back_url_admin=*
Disallow: /*index.php$
И понятно, что это не полный текст файла роботс, потому что внутри ещё закрыты служебные папки.
А дальше самое интересное!
В гугл-вебмастере по проиндексированным страницам ой как видны наши дубли. Что делаем: сообщаем роботу, что надо сканировать, а что не надо – там выпадающими списками удобно реализованы возможные варианты.
Когда мы переносили самописный старый сайт в Битрикс, мы все поддомены делали на одном уровне с корневой папкой головного сайта (каюсь и больше никогда так делать не буду), то есть для поисковой системы у нас получалась хренова туча дублей.
Поясню:
Сайт универа доступен по адресу www.bsu.edu.ru/bsu/
Сайт исторического факультета (например) доступен по адресу if.bsu.edu.ru/if/
Но так как по факту папки лежат на одном уровне. То для поисковой системы ой какие нехорошие дубли делаются:
www.bsu.edu.ru/if/ — будет сайт исторического факультета,
if.bsu.edu.ru/bsu/ — будет сайт университета.
Понимаю, что облажались, будем исправлять.
Для начала проверен реферер или так называемая «склейка»:
На сервере делается грамотно всё так, чтобы bsu.edu.ru, www.bsu.edu.ru, www.bsu.edu.ru/, www.bsu.edu.ru/bsu воспринимались как www.bsu.edu.ru/bsu/
То есть, всё дело в ПАЛКЕ в одном слэше, но неприятненько. Да, это, кстати, было настроено сразу, исправлять не пришлось.
Зато теперь я голову сломала себе — надо указать ведь канонический (предпочитаемый) адрес для кучи факультетских сайтов и подразделений. Это же миллионы ссылок.
Ответ оказался прост, как ларчик и вот его волшебный кусок кода, как избегать дублей страниц в Битриксе и как этого добиться в куче шаблонов сайта сразу:
<?
$aURI = $_SERVER[‘SERVER_NAME’].$_SERVER[‘REQUEST_URI’];
$aLink = «www.bsu.edu.ru/bsu»;
$aCannonical = stripos($aURI, $aLink);
?>
<?if ($aCannonical !== false):?>
<link rel=»canonical» href=»http://<?echo $aURI;?>» />
<?endif;?>
Я здесь использую функцию stripos потому, что она нечувствительна к регистру.
Но и это еще не всё, потому что по-хорошему надо предусмотреть, что если посетитель или робот пошел по ссылке www.bsu.edu.ru/if/ ? то его редиректом отправило бы по назначению на if.bsu.edu.ru/if/
Головоломка решена!
Оптимальный вариант — сделать на сервере через mod_rewrite нужные пляски исключительно для порядка отображения, чтоб посетители сайта не вводились в заблуждение.
В крайнем случае можно сделать (если сайтов не много, или нет возможности обратиться к админу сервера) локальный редирект через битриксовый php_interface/init.php, добавив туда кусочек кода:
if($_SERVER[«HTTP_HOST»]==»www.bsu.edu.ru/if/»){
LocalRedirect(«http://if.bsu.edu.ru/if/»);
}
Но в таком случае, если посетитель вдруг решит поглумиться и набрать строку адреса с параметрами — рискуем получить одно и то же по разным урлам.
Повторюсь, не критично, но для порядка хотелось бы и этого избегать.
Не наступайте на такие грабли, друзья!
p.s.: весной 2017 года наконец-то мне удалось достучаться до адекватного админа NGnix, который написал разграничение доступа сайтов. Потребовалось открыть им только папки main, modules, upload, functions и templates. Увы, было организовано всё так, что папки сайтов лежат на одном уровне в корне всего сайта. Теперь же, благодаря символьным ссылкам на нашем собственном хостинге мы считай на 1 лицензионной версии битрикс имеем более 25 сайтов. Изначально, когда сам битрикс приобретался — была редакция битрикс, интеграция с AD+LDAP и число сайтов неограничено. Так и осталось, пилилось многое в компонентах, разгребаем косяки после каждого обновления, а техподдержка битрикса офигевает от такого количества наших «инфоблоков» и решений с костылями. Но помогают исправлять многое очень оперативно.
Доступа к линуксовому серверу не имею, чтобы поделиться кодом, но знаю, что велись эксперименты с DOCUMENT_ROOT.