- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
В 2023 году 36,9% всех DDoS-атак пришлось на сферу финансов
А 24,9% – на сегмент электронной коммерции
Оксана Мамчуева
Все что нужно знать о DDоS-атаках грамотному менеджеру
И как реагировать на "пожар", когда неизвестно, где хранятся "огнетушители
Антон Никонов
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Ув. коллеги,
приветствую!
Завтра начнем переезд на HTTPS. Сайт - более 50'000 проиндексированных страниц. Моб. версия на отдельном доме - m.site.ru , что несколько осложняет дело. HTTPS-версия сейчас является неглавным зеркалом.
Переехать планируем плавно, не потеряв ни в Гугле. ни в Яндексе. 301 только после сообщения о переклейки. Столкнулись с головоломкой по настройкам alternate и canonical , очень интересно ваше мнение.
→ Сейчас в индексе: http: site.ru и m.site.ru (20'000 страниц у Яши) на http-версиях , между собой связаны тегами alternate (для основной версии) и canonical (для мобильных страниц).
→ Начитались страшилок про 301 и Яндекс, попробуем переехать с помощью robots.txt host, canonical, alternate и ВМ.
→ Основная версия - переводим http на https (до склейки в Я) с помощью rel canonical
→ Alternate для основной https-версии будет выглядеть как "https m.site.ru"
→ rel canonical мобильной версии, по идее, должен вести на основную версию site.ru . Но как быть с необходимостью показать, что канонический адрес мобильной страницы теперь не http m.site.ru , а https m.site.ru ?
→ Как должен выглядеть alternate основной http версии?
Навскидку:
(1) 2 альтернейта: http и https ; (не слышал про такое извращение, и куда направится пользователь с моб.устройства / робот)
(2) беспротокольный относительный alternate к домену, вида "//m.site.ru" ; (круто, но что будет, когда робот попадет на https-моб. версию, ведь в индексе уже есть http m.версия страницы)
(3) Один альтернейт на https m.версию (круто, но что будет, когда робот попадет на https-моб. версию, ведь в индексе уже есть http m.версия страницы)
Вот такая головоломка.
Заранее спасибо за мнения,
с уважением!
Вот что еще интересно.
Рекомендации Яндекса воздержаться от 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 ----------
Вот что еще интересно.
Рекомендации Яндекса воздержаться от 301 до склейки зеркал, полагаю, связаны с диссонансным индексированием. Т.е. текущая http страница будет удалена роботом, поскольку является редиректом, но добавление новой страницы не пойдет влет, поскольку робот имеет понимание (до склейки): в паре http / https site.ru , https-версия является неглавным зеркалом.
Но ведь при наличии canonical на https, http-страницы точно так же должны вылетать из индекса (неканоническая), при этом старые указания (главное и неглавное зеркало) по-прежнему распространяется. Т.е. почему в одном случае не идет по плану, а в другом - должно пройти гладко, кхм.
есть такие проблемы) всему виной - задержки и тормознутость Яндекса в корректной обработке 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 .
→ rel canonical мобильной версии, по идее, должен вести на основную версию site.ru . Но как быть с необходимостью показать, что канонический адрес мобильной страницы теперь не http m.site.ru , а https m.site.ru ?
Канонические ссылки работают для одного домена (по крайней мере для Яндекса). То есть указание для m.site/xxx канонической станицей site/xxx ничего не даст, т.к. это технически разные домены. По своему опыту скажу, что из-за этого как раз иногда в серп пролезают мобильные страницы вместо десктопных, но это в порядке глюка и быстро проходит.
Полагали, достаточно связать страницы m.site.ru и site.ru между с собой с помощью canonical и alternate. Промахнулись?
Подозреваю, отсюда проблема, которая меня давно беспокоит - зачем Яндексу индексировать страницы m.site .
вот что говорит яндекс каноникал не работает, но использовать можно
а вот что говорит гугл - надо каноникал.
Отсюда вывод - делать альтернате и каноникал надо)
а вот что писать в 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 через ВМ зеркалами с указанием главного? Кто что думает, какой опыт?