Правильная склейка сайтов для Яндекса и Гугла + Правильная склейка доменов с www и без, для всех ПС!
Добрый день, 27 мая Яндекс, наконец-то склеил один из моих сайтов и определил главное зеркало. На всё это понадобилось почти 2 месяца. В этом посте я хочу описать всё что я делал для этого.
В начале Апреля я приобрёл себе сайт — pozitiv.16mb.com (мое самое первое детище). Но мне не понравилось доменное имя, да и привязано оно было к хостингу, то есть владельцем домена была Хостинг компания. Поэтому я решил перенести сайт на интернациональный домен.
Зарегистрировал домен p0zitiv.ru и перекинул на него сайт. Чтобы они были идентичными.
Подготовление к склейки сайтов
Многие советуют, что правильно клеить сначала для Яндекса, после того как он склеит можно начинать склеивать для Google. Потому что у этих поисковых систем отличаются методы склейки. Для Google используется 301 редирект, а Яндекс выявляет главное зеркало через директиву host в robots.
txt. Но такой способ меня не устраивал, я хотел сразу склеить сайты для двух поисковиков одновременно, чтобы не терять время.
Склеиваем сайт под Google
Первым делом, надо перенести сайт на новый домен так, чтоб всё было идентично старому сайту.
После этого следует заняться настройкой под склеивания в Google. Для этого на старом сайте(pozitiv.16mb.com), я установил 301 редирект в файле .htaccess, выглядит он вот так:
Options +FollowSymLinks RewriteEngine on RewriteRule (.*) http://p0zitiv.ru/$1 [R=301,L]
То есть полное перенаправление со всех страниц на новый домен p0zitiv.ru.
После этого в Панели «Вебмастер Google» для старого домена указал новый адрес:
Вот и всё, настройки для склеивания сайта под Google закончены. А дальше самое интересное, настроить сайт так, чтобы Яндекс смог выявить главное зеркало, в данном случае домен p0zitiv.ru.
Определяем главное зеркало сайта для Яндекса
Напомню ещё раз, Яндекс для склейки сайтов использует файл robots.
И так, первым делом надо добавить директиву host в файле robots.txt на старом сайте. У моего старого сайта pozitiv.16mb.com, файл robots.txt выглядит вот так:
User-agent: Yandex Host: p0zitiv.ru
Важно! Для кириллических доменов в директиву Host домен необходимо писать в punycode (пуникодом)
После того, как указали главное зеркало, надо отключить редирект для robots.txt, отключается он в файле .htaccess, вот этим кодом:
<FilesMatch "robots.txt$"> RewriteEngine off </FilesMatch>
Теперь при запросе ботом Яндекса файла http://pozitiv.
(.*)$ http://p0zitiv.ru/$1 [R=301,L]
То есть полное перенаправление со всех страниц на новый домен p0zitiv.ru.
После этого в Панели «Вебмастер Google» и в панели «Яндекс.Вебмастер» необходимо указать основное зеркало сайта.
Вот и все настройки для склеивания доменов с www и без www закончены. А чтобы Яндекс смог выявить главное зеркало, в данном случае домен p0zitiv.ru, надо будет проделать трюк (описывал выше) с файликом robots.txt. На всякий случай напомню:
После того, как указали главное зеркало, надо отключить редирект для robots.txt, отключается он в файле .htaccess, вот этим кодом:
RewriteEngine off
Нюансы
Так же у меня возникла проблема — как добавить сайт в панель вебмастер Яндекса и Гугла?
Ведь надо подтвердить права на сайт, путём размещения файлов в корень сайта. Для этого, им тоже требуется отключить редирект чтобы проверяющие боты Яндекса и Google не уходили на новый домен.
(google495dea0554e801b5\.html|yandex_748544efecfe9337\.html)$ — [L]
Проверить на склейку в обоих ПС можно сервисом от xseo.in
Вывод
Google склеил сайт примерно за две недели, трафик с Google сохранился полностью. Яндексу на определение главного зеркала, потребовалась приблизительно два месяца, после этого я получил вот такое письмо в «Панель Вебмастер»:
Трафик с Яндекса после того как поставил 301 редирект упал практически до нуля и вот после 27 мая (день склейки) начал потихоньку восстанавливаться:
На этом всё, спасибо за внимание.
в каких случая и для чего используется
#SEO #Веб-разработка
Под склейкой зеркал (или доменов) нужно понимать процедуру объединения как минимум 2 сайтов (зеркал) в один.
Такая процедура приводит к тому, что один из сайтов становится главным. За вторым сайтом будет закреплен статус зеркала. Зеркало — абсолютная копия основного ресурса, которая находится на другом сервере или доменном имени.
Сайты-зеркала могут иметь такой вид:
- ресурс без WWW и с WWW в начале доменного имени;
- ресурс с HTTPS:// и HTTP://;
- 2 разных домена, но их контент на 80-90% одинаков;
- 1 ресурс, который размещается на отдельных серверных мощностях.
Для чего выполняется склейка зеркал
Современные поисковики очень «не любят» сайты-дубли (аналогичные друг другу ресурсы). В выдаче они просто не могут показать 2 сайта с абсолютно одинаковым наполнением. Они автоматически примут их за зеркала и выполнят склейку, даже если эти ресурсы принадлежат одному и тому же человеку. Индексироваться в выдаче поисковика будет лишь один сайт, которому будет присвоен статус главного.
На практике при склейке довольно часто главным становится не тот ресурс. Для избежания этой проблемы стоит предварительно прописать правильные условия в директиве: указать ссылку на основное (главное) зеркало и все его копии, если их несколько.
Инструкция по самостоятельной склейке:
- для Яндекса — добавить строчку host около главного ресурса в robots.txt или настроить его в Яндекс.Вебмастере;
- для Гугл — зайти в Search Console и выполнить в системе необходимую настройку;
- общая рекомендация — настроить редирект 301.
После вышеописанных манипуляций трафик со всех второстепенных ресурсов будет перенаправлен на главный. Если зеркала ранее имели какой-то ссылочный вес, то после их склейки он также перенаправляется основному ресурсу.
В каких случаях используется склейка
Склейка доменов, как правило, выполняется:
- При переносе ресурса на другое доменное имя. Для того, чтобы сохранить все показатели («пузомерки») ресурса (например, тИЦ).
Если ресурс достиг очень высоких «пузомерок», то после проведения склейки картина может серьезно измениться, причем не в лучшую сторону. - При неверном распределении приоритетов поисковой системы, когда Яндекс или Гугл назначили главным не тот сайт.
- При необходимости одновременно расположить сайт на разных доменах. Когда названия компании можно написать по-разному и веб-мастеры приобретают все домены, которые подходят по смыслу: telefon.ru, telefon.com, tele-fon.ru и др.
- Для обеспечения сохранности данных и максимально стабильной работы сайта при возникновении каких-либо проблем в работе какого-либо «запасного» ресурса.
Если ресурс достиг очень высоких «пузомерок», то после проведения склейки картина может серьезно измениться, причем не в лучшую сторону.— Подтверждение существования записей GLUE
Задай вопрос
спросил
Изменено 11 лет, 8 месяцев назад
Просмотрено 647 раз
У меня есть два домена, example1.
При таком сценарии я ожидаю, что мне не понадобятся никакие собственные записи GLUE, и я их не создавал. Однако, используя информацию в этом посте, я проверил наличие записей GLUE с помощью инструмента раскопок.
Когда я запрашиваю h.gtld-servers.net (или любой другой) серверы имен example2.com, я вижу ns1.example1.com и ns2.example1.com в разделе «полномочия», а также их IP-адреса. в разделе «Дополнительно».
;; РАЗДЕЛ ВОПРОСОВ: ;example2.com. В НС ;; ОТДЕЛ ПОЛНОМОЧИЙ: example2.com. 172800 В NS ns1.example1.com. example2.com. 172800 В NS ns2.example1.com. ;; ДОПОЛНИТЕЛЬНЫЙ РАЗДЕЛ: ns1.example1.com. 172800 В А 192.0.2.1 ns2.example1.com. 172800 В А 198.51.100.1
Насколько я понимаю, это означает, что для этих серверов имен существуют записи GLUE, но мой регистратор настаивает на том, что их не существует.
Кто прав? Мой регистратор или связанный пост? Всегда ли записи в разделе «Дополнительно» указывают на наличие записей GLUE или может быть другая причина?
Заранее большое спасибо.
- система доменных имен
- сервер имен
- DNS-хостинг
- клей-запись
5
То, что вам не нужны записи GLUE, не означает, что их нет.
Возможно, ваш доменный провайдер автоматически создает эти записи для вас, когда вы вводите поддомены другого домена с ним как записи ресурсов NS.
4
Если example1.com использует ns1.example1.com и ns2.example1.com, потребуются связующие записи. Поскольку записи NS и SOA будут указывать на один и тот же домен, DNS нужны эти связующие записи, чтобы иметь возможность рекурсивно выполнять любые записи в домене с вашего сервера (в конце концов, что-то должно указывать на ваш сервер).
Например, example2.com, если он используется третьей стороной и предполагается, что у этой стороны есть собственные серверы имен (скажем, ns1.domain.com и ns2.domain.com), тогда на example2.com не должно быть клея или ns. записи. Вместо этого должна быть запись SOA, указывающая на серверы domain.com. По сути, это говорит DNS, что нужно обратиться к этим серверам, потому что TLD не знает, где находится следующий прямой шаг.
2
Зарегистрируйтесь или войдите в систему
Зарегистрируйтесь с помощью Google
Зарегистрироваться через Facebook
Зарегистрируйтесь, используя адрес электронной почты и пароль
Опубликовать как гость
Электронная почта
Требуется, но не отображается
Опубликовать как гость
Электронная почта
Требуется, но не отображается
Нажимая «Опубликовать свой ответ», вы соглашаетесь с нашими условиями обслуживания, политикой конфиденциальности и политикой использования файлов cookie
.
Подтверждение существования клеевой записи с помощью dig? : dns
За последние два десятилетия мне всего несколько раз приходилось настраивать свежие авторитетные DNS-серверы. А в свою очередь, только клеить записи пришлось для них и того меньше.
Однако это время снова пришло, и подтверждение существования клейкой записи кажется не таким, каким я его помню.
Насколько я помню, вы должны были:
определить авторитетные серверы для TLD любого имени хоста вашего сервера имен/клеевой записи, на которое заканчивается.
запросите один из этих серверов TLD напрямую для записи A для имени хоста вашего сервера имен/клеевой записи.
Допустим, мой домен EXAMPLE.COM, а планируемое имя хоста для сервера имен, на котором он будет размещен, будет NS1.EXAMPLE.COM.
Я захожу в свой интерфейс регистратора и 1) создаю связующую запись для NS1.EXAMPLE.
COM, указывающую на IP-адрес сервера имен, и 2) устанавливаю первичный сервер имен для EXAMPLE.COM как NS1.EXAMPLE.COM.
Чтобы подтвердить существование связующей записи, я чувствую, что всегда запускал: dig @a.gtld-servers.net NS1.EXAMPLE.COM и получил запись A с серверов TLD.
Я ожидал:
dig @a.gtld-servers.net NS1.EXAMPLE.COM ; <<>> DiG 9.10.3-P3 <<>> @a.gtld-servers.net ns1.example.com ; (найден 1 сервер) ;; глобальные параметры: +cmd ;; Получил ответ: ;; ->>HEADER<<- код операции: QUERY, статус: NOERROR, id: 10473 ;; флаги: qr rd; ЗАПРОС: 1, ОТВЕТ: 0, АВТОРИЗАЦИЯ: 2, ДОПОЛНИТЕЛЬНО: 3 ;; ВНИМАНИЕ: рекурсия запрошена, но недоступна ;; ДОПОЛНИТЕЛЬНЫЙ ПСЕВДОРАЗДЕЛ: ; ЭДНС: версия: 0, флаги:; UDP: 4096 ;; РАЗДЕЛ ВОПРОСОВ: ;ns1.example.com. В ;; РАЗДЕЛ ОТВЕТОВ: ns1.example.com. 172800 IN A;; ОТДЕЛ ПОЛНОМОЧИЙ: пример.com. 172800 В NS ns1.example.com. пример.com. 172800 В NS ns2.example.com. ;; ДОПОЛНИТЕЛЬНЫЙ РАЗДЕЛ: ns1.example.com. 172800 IN A ns2. ;; Время запроса: 10 мс ;; СЕРВЕР: 192.5.6.30#53(192.5.6.30) ;; КОГДА: воскресенье, 30 августа, 22:37:11 по восточному поясному времени 2020 г. ;; РАЗМЕР MSG rcvd: 115
example.com. 172800 IN A , но вместо этого я просто получаю:
; <<>> DiG 9.10.3-P3 <<>> @a.gtld-servers.net ns1.example.com ; (найден 1 сервер) ;; глобальные параметры: +cmd ;; Получил ответ: ;; ->>HEADER<<- код операции: QUERY, статус: NOERROR, id: 10473 ;; флаги: qr rd; ЗАПРОС: 1, ОТВЕТ: 0, АВТОРИЗАЦИЯ: 2, ДОПОЛНИТЕЛЬНО: 3 ;; ВНИМАНИЕ: рекурсия запрошена, но недоступна ;; ДОПОЛНИТЕЛЬНЫЙ ПСЕВДОРАЗДЕЛ: ; ЭДНС: версия: 0, флаги:; UDP: 4096 ;; РАЗДЕЛ ВОПРОСОВ: ;ns1.example.com. В ;; ОТДЕЛ ПОЛНОМОЧИЙ: пример.com. 172800 В NS ns1.example.com. пример.com. 172800 В NS ns2.example.com. ;; ДОПОЛНИТЕЛЬНЫЙ РАЗДЕЛ: ns1.example.com. 172800 IN Ans2.example.com. 172800 IN A ;; Время запроса: 10 мс ;; СЕРВЕР: 192.5.6.30#53(192.5.6.30) ;; КОГДА: воскресенье, 30 августа, 22:37:11 по восточному поясному времени 2020 г.
