HTTPS | Переезд-головоломка: m.site.ru, canonical, alternate

Вот что еще интересно.

Рекомендации Яндекса воздержаться от 301 до склейки зеркал, полагаю, связаны с диссонансным индексированием. Т.е. текущая http страница будет удалена роботом, поскольку является редиректом, но добавление новой страницы не пойдет влет, поскольку робот имеет понимание (до склейки): в паре http / https site.ru , https-версия является неглавным зеркалом.

Но ведь при наличии canonical на https, http-страницы точно так же должны вылетать из индекса (неканоническая), при этом старые указания (главное и неглавное зеркало) по-прежнему распространяется. Т.е. почему в одном случае не идет по плану, а в другом - должно пройти гладко, кхм.

"попробуем переехать с помощью robots.txt host, canonical, alternate и ВМ."

для Яндекса - всё верно.

мобильная версия так же должна быть на https, и на ней стоит canonical на основной сайт с https

что у вас сейчас в роботсе мобильной версии в host? Если он не склеен в одну группу с основным сайтом, в host надо поменять на https://m.site.ru и сделать переезд. Если мобильный сайт склеен в группу в основным сайтом - то в роботсе ставьте https://site.ru

"→ Как должен выглядеть alternate основной http версии?" можно оставить как есть.

Потому что, как только у вас станет основное зеркало https, то вы настроете же 301 редирект? И тогда что указано в альтернейт версии http будет неважно

сразу посоветую robots и sitemap.xml версии http не редиректить, в сайтмапе урлы с https. Робот Яшки должен приходить на http роботс и видеть в host https://site.ru

---------- Добавлено 20.07.2017 в 09:51 ----------

есть такие проблемы) всему виной - задержки и тормознутость Яндекса в корректной обработке canonical и переклейки вообще. "Понять и простить"

То, что вы сначала подклеили https как неосновное зеркало - очень правильно! Это ускорит переезд значительно! Многие приклеивают с нуля https и делают его основным - на это уходит куда больше времени, а на больших сайтах так вообще косячно все проходит.

Ув. коллега, спасибо за советы.

→ Моб. версии http и https тоже склеены как зеркала, главным сейчас является http m.site.ru . Переводить планируем сразу и все: основная + мобильная (слава Джа, региональность делали через папки, с доп. поддоменами с ума бы сошли)

→ Да. Как только Яндекс сообщит, что основным зеркалом является https-версия, постранично поставим 301 на https.

→ 2 роботс.тхт с хостами https, 2 сайтмэпа и т.п. - все это подготовлено уже. После постановки 301-х планируем не накидывать на роботс и сайтмэп http-версии редиректы - всю дорогу робот сможет читать их.

→ По поводу alternate по-прежнему непонятно, как лучше оформить. Идея с двумя альтернейтами - похоже, самая плохая. Просто не париться и оставить относительным (вида /catalog/) или перевести на беспротокольные относительные (//m.site.ru/catalog/).

→ Появилась еще одна странная идея. Мягко без 301 до склейки переводить основную версию, а на мобильную сразу поставить 301 с http m.site на https m.site .

→ Также вообще не понятно, зачем Яндексу в индексе мобильные страницы, ведь все они canonical основной версии сайта. Складывается впечатление, что что-то идет не так либо на нашей стороне, либо на стороне Я.

алтернате я бы сделал так: http site ru --> http m.site.ru и https site ru --> https m.site.ru

то есть наверна оставил так, как есть сейчас. Переезд в Яндексе у вас будет как переключение в один прекрасный момент на https в выдаче (станет основное зеркало). До этого момента такие альтернате будут верными. А после переключения сделаете 301 и будет неважно уже, какие альтернате на http версии.

"→ Появилась еще одна странная идея. Мягко без 301 до склейки переводить основную версию, а на мобильную сразу поставить 301 с http m.site на https m.site "

не советовал бы.

кстати, так и не понял, у вас мобильный сайт в группе зеркал с основным? типа вот так https://s.mail.ru/EYNe/Sr377wRU4

→ кстати, так и не понял, у вас мобильный сайт в группе зеркал с основным?

Ув. коллега, m.site не объединен в группу зеркал с сайт.ру

Т.е:

site.ru , www.site.ru , https.site.ru - объединены в группу зеркал ;

m.site , www.m.site и т.п . - в другую группу зеркал. В панели WM это выглядит так:

Полагали, достаточно связать страницы m.site.ru и site.ru между с собой с помощью canonical и alternate. Промахнулись?

Подозреваю, отсюда проблема, которая меня давно беспокоит - зачем Яндексу индексировать страницы m.site .

Канонические ссылки работают для одного домена (по крайней мере для Яндекса). То есть указание для m.site/xxx канонической станицей site/xxx ничего не даст, т.к. это технически разные домены. По своему опыту скажу, что из-за этого как раз иногда в серп пролезают мобильные страницы вместо десктопных, но это в порядке глюка и быстро проходит.

вот что говорит яндекс каноникал не работает, но использовать можно

а вот что говорит гугл - надо каноникал.

Отсюда вывод - делать альтернате и каноникал надо)

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

→ Канонические ссылки работают для одного домена (по крайней мере для Яндекса).

Для Яндекса все так. Однако, как указал ув. коллега Recoba выше, canonical необходим для Google.

→ а вот что писать в host мобильного - вопрос неоднозначный.

Яндекс, насколько я понимаю, рекомендует указывать в моб. версии хост site.ru только при полной идентичности контента. Элемент-в-элемент. У нас (уверен, как 99% других m.site) есть определенные различия: каких-то элементов основной версии попросту нет на странице, где-то нет описаний - только каталог с предложениями и т.п.), поэтому указываем хостом m.site.ru (сейчас еще http , во время перехода - https).

Назрел еще один интересный вопрос. Как оно вообще должно быть правильно? Место мобильным страницам в основном индексе или нет.

Полгода назад в Гугле мне дали однозначный ответ - страниц мобильной версии в индексе поиска быть не должно. Наличие этих страниц - ваши ошибки. Индексация Яндексом моб.страниц - это его личная придурь (почти дословно).

Т.е. на примере Гугла:

site:m.site.ru - Результатов: примерно 4 570 (0,22 сек.) , из них в выдаче можно пройти 6 страниц. Причем все, что мы видим в этой выдаче, не проиндексировано основной версии site.ru (т.е. берем страницу m.site.ru/stran1/ , пробиваем ее операторам info , затем берем аналогичную страницу site.ru/stran1/ - пробиваем оператором info и видим, что ее нет в индексе)

А вот что касается Яндекса, то непонятно ничего. Однозначных рекомендаций я не нашел. Напротив, в гайдах есть советы про добавления m.site.ru в вебмастер, чтобы контролировать ее индексацию.

В яндексе у нас ситуация такая:

url:m.site.ru* (либо оператор site:m.site.ru) - 17'000 страниц

url:site.ru* - 51'000 страниц (соответствует данным ВМ), либо site:site.ru - 65'000 страниц (не сходится с ВМ)

Причем для любой проиндексированной моб. страницы (например: m.site.ru/stran1/) в индексе найдется родитель url:site.ru/stran1/ .

Отсюда сомнения, что так и должно быть. Может быть, действительно необходимо клеить m.site и site через ВМ зеркалами с указанием главного? Кто что думает, какой опыт?