Навигация по сайту

Популярные статьи

Понимание индексации на мобильных устройствах (1/3): непосредственное влияние на SEO

От: Синди Крум

Объявление Google Mobile-First Indexing вызвало много дискуссий, но пока что никто не слишком обеспокоен. Это может быть связано с тем, что Google уже более года рекламирует различные корпоративные инициативы «Mobile-First», но это также может быть связано с тем, что Google, похоже, изменила свою процедуру запуска обновлений или, по крайней мере, «мобильных» обновлений. Если недавняя история является признаком будущего, новый процесс Google выглядит примерно так:

  • Публично объявлять об изменениях заранее (иногда даже с датами и сроками)
  • Сдвигайте корректировки рейтинга медленно (а не все сразу)
  • Предварительно объявляйте о корректировках и связанных обновлениях по мере необходимости

Этот шаблон начался с обновления Mobile-Friendly (Mobilegeddon) и продолжился модификациями, связанными с внедрением приложений, HTTPS и глубокими связями, а также с различными объявлениями AMP.

Эта новая стратегия выпуска, вероятно, обусловлена ​​влиянием, которое машинное обучение оказывает на алгоритмические оценки, но ключевое преимущество для SEO состоит в том, что алгоритмические изменения больше не нарушают ранжирование сразу после запуска. Это медленное развертывание привело к тому, что многие из последних обновлений изначально подвергались насмешкам за минимальное влияние, но со временем все эти изменения окажутся весьма значительными. Переход на Mobile-First Indexing не станет исключением.

Эта статья является первой в серии из трех статей, которая помогает SEO понять долгосрочное и краткосрочное влияние, которое изменение Google на индексацию с мобильного прежде всего окажет на стратегии SEO и лучшие практики. Он начнется с краткой истории мобильной индексации, а затем расскажет, как SEO могут сделать существующий сайт совместимым с Mobile-First Indexing. Во второй статье мы обсудим критическое расстояние, которое Mobile-First Indexing Судя по всему, между URL-адресами и соответствующим контентом допускается растущий толчок к размещению контента в облаке Google и то, как мы можем ожидать, что эти концепции повлияют на сеть в целом в будущем. В заключительной статье серии будут рассмотрены различные варианты разработки, которые Google рассматривает изначально Mobile-First когда они должны быть использованы и большие темы, которые объединяют их все вместе.

Краткий обзор мобильного SEO и индексации мобильных устройств

От:   Синди Крум   Объявление Google Mobile-First Indexing вызвало много дискуссий, но пока что никто не слишком обеспокоен

Спасибо Питеру Кэмпбеллу за потрясающий имидж. http://www.petecampbell.com/seo/mobile-seo-guide/

Исторически сложилось так, что Google боролся с разными мобильными индексами и разными мобильными сканерами. Вкратце, во времена WAP-сайтов, предназначенных только для мобильных устройств, у Google был индекс, специфичный для мобильных устройств, но как только цвета и изображения стали обычным явлением в дизайне мобильных сайтов, результаты мобильного поиска стали включать как мобильные, так и настольные страницы. Когда мобильные поддомены mDot были популярны, мобильные страницы были проиндексированы на основе их отношения к странице рабочего стола, которая обычно определялась типом настроек сервера, называемым «Обнаружение и перенаправление агента пользователя». Мобильные страницы с соответствующей страницей на рабочем столе для Google было трудно обнаружить и проиндексировать, если карта сайта не была отправлена ​​с URL-адресами для мобильных устройств или кто-то активно связался со страницы на рабочем столе со страницей, ориентированной на мобильный телефон. Даже тогда Google было трудно определить, когда мобильные страницы должны ранжироваться, потому что мобильный контент иногда должен был превосходить своих настольных аналогов, у которых было больше истории и положительных сигналов ранжирования SEO, несмотря на то, что алгоритмически выглядел как дублированный контент.

Диаграмма Google для правильного обнаружения и перенаправления агента пользователя: https://developers
Диаграмма Google для правильного обнаружения и перенаправления агента пользователя: https://developers.google.com/webmasters/mobile-sites/mobile-seo/common-mistakes

Чтобы решить эту проблему, Google предложил веб-мастерам указать, что на странице рабочего стола есть альтернативная мобильная версия, добавив ссылки «rel = alternate» и «rel = canonical» на HTML-код обеих страниц. Тег «rel = alternate» на странице рабочего стола будет проиндексирован и вызовет мобильный сканер для просмотра мобильной версии страницы, указанной в теге. Таким образом, он также может быть просканирован и проиндексирован. Мобильная версия страницы не учитывалась как дублированный контент и передавала свое значение SEO в настольную версию страницы, используя тег rel = canonical, который ссылался на настольную версию страницы.

Этот процесс был подвержен ошибкам и требовал значительных ресурсов. Поэтому, чтобы минимизировать проблему, Google начал активно поощрять веб-мастеров обновлять свои сайты до Responsive-Design. Поскольку руководящим принципом было создание одного адаптивного веб-сайта, который работал бы как на мобильных, так и на настольных устройствах, Google удалила сканер для мобильных устройств и начала сканировать все (как для настольных компьютеров, так и для мобильных устройств) как смартфон. (На данный момент сканирование было мобильным, но индексирование все еще основывалось на старых стандартах настольных компьютеров.) Хотя Responsive-Design решил некоторые проблемы сложности с обходом и индексированием, он добавил новые проблемы.

Использование медиазапросов CSS и JavaScript для адаптации контента для одного URL для соответствия разным размерам экрана имеет тенденцию резко увеличивать задержку большинства веб-сайтов - особенно на мобильных телефонах, где количество запросов туда-обратно на сервер для различных частей контента встроено в HTML значительно замедлил работу. С тех пор Google сосредоточил внимание на мобильной SEO и руководящих принципах разработки на скорости, пытаясь научить и убедить веб-мастеров создавать чистые и эффективные сайты с учетом важности рендеринга критического пути . (Рендеринг критического пути - это практика стратегического упорядочивания внутренних и внешних элементов страницы для оптимизации времени загрузки.) Цель состояла в том, чтобы помочь сделать сайты более быстрыми и более удобными, даже в медленных мобильных сетях. Но в конечном итоге Google осознал, что неизменно великолепный рендеринг критического пути был недоступен большинству веб-мастеров и квалифицированных групп разработчиков, особенно когда адаптивный дизайн стал частью стандартных требований. Страницы становились больше и медленнее из-за всего кода, необходимого для размещения дополнительных переменных, необходимых для того, чтобы сделать страницу адаптивной.

Спасибо Луи Хольцману за иллюстрацию, показывающую разницу между веб-сайтом и веб-приложением: https://www
Спасибо Луи Хольцману за иллюстрацию, показывающую разницу между веб-сайтом и веб-приложением: https://www.linkedin.com/pulse/web-application-vs-website-whats-difference-louis-holzman

Со временем Google также обнаружил, что даже когда в игре использовался сильный рендеринг критического пути, при мобильной и настольной визуализации страницы адаптивного дизайна все еще возникали серьезные проблемы с кэшированием и сжатием, часто возникающие из-за CDN (Content Distribution Network). Эти проблемы с кэшированием и сжатием часто были сложны для решения SEO и командами разработчиков, и некоторые из них были настолько значительными, что они в любом случае делали всю работу Critical-Path Rendering практически неактуальной. Хотя некоторые умные веб-мастера начали использовать усовершенствованные протоколы рендеринга, чтобы ускорить процесс (предварительный кеш, предварительный выбор и предварительный рендеринг), большинство из них просто создавали медленные веб-сайты.

Это приближает нас к настоящему времени, когда пользователи требуют все более быстрых веб-сайтов, которые выглядят и ведут себя больше как их более быстрые родственники в приложениях. Они хотят «мобильные веб-приложения» вместо «мобильных веб-сайтов». Эти требования создают огромную нагрузку для разработчиков, поскольку весь JavaScript, необходимый для того, чтобы веб-сайты выглядели и чувствовали себя как приложения. Это создает еще большую задержку во времени загрузки сайта. Чтобы разгрузить часть кода, веб-мастера обращаются к выборочному обслуживанию и прогрессивному рендерингу, который оставляет некоторое содержимое страницы на сервере до тех пор, пока пользователь не запросит его. JavaScript и HTML5 используются для запроса контента с сервера, но он извлекается только по мере необходимости. Это помогает сократить время загрузки сайта, но поскольку для этой структуры не требуется, чтобы уникальный контент имел уникальный URL-адрес, мобильным веб-приложениям, созданным без чрезмерной заботы о SEO, может быть очень сложно проиндексировать Google. Именно взаимодействие всех этих сложных элементов привело к необходимости индексации Mobile-First.

Основы индексации Mobile-First

Mobile-First Indexing - это следующая попытка Google улучшить и стандартизировать веб-разработку, стимулируя изменения потенциальным повышением рейтинга в поисковых системах. Это важно, потому что исторически Google основывал все свои оценки индексации и большую часть своих рейтинговых оценок на настольной версии страницы. В то время как большинство изменений алгоритма связаны с положительными или отрицательными факторами ранжирования, индексирование Mobile-First отличается, потому что оно изменяет оценки перед алгоритмом страницы. Индекс Mobile-First не будет генерировать новый отдельный индекс Mobile-First. Вместо этого он изменит способ добавления контента в существующий индекс. Проще говоря: если ваши новые веб-страницы не проходят эту первоначальную оценку, они могут быть не включены в индекс Google, и помните, что если веб-страница не включена в индекс Google, у нее абсолютно нет шансов получить рейтинг.

Не волнуйтесь, хотя. Google не будет перезаписывать хорошо проиндексированный настольный контент мобильным контентом, который имеет меньше сигналов ранжирования и меньше информации. Это будет индексация ТОЛЬКО для мобильных устройств, а это не то, что объявляет Google. Если ваш веб-сайт проиндексирован сейчас, он, вероятно, останется в индексе, особенно если он является частью 80% веб-сайтов, которые удовлетворяют базовым требованиям для получения скрытого теперь обозначения для мобильных устройств. Напоминаем, что для того, чтобы быть мобильным, ваш контент должен иметь JavaScript и CSS, пригодные для сканирования, и (как ни странно подчеркивается в оценке инструмента Google для мобильных устройств), контент должен быть быстрым, надлежащего размера, удобным и привлекательным, когда он представлены на мобильном телефоне. Хотя метка больше не представлена ​​в поисковой выдаче, требования остаются и, вероятно, весьма важны для индексации с мобильного устройства.

Индексирование с мобильных устройств также может указывать на то, что Google становится менее зависимым от традиционных ссылок и HTML-URL для ранжирования. Помните, что стратегии мобильного SEO никогда не фокусировались на ссылках или построении ссылок, потому что рейтинг определялся главным образом настольным сайтом, где разработчикам было проще и логичнее управлять ссылками. Mobile-First Indexing может позволить абсолютному расположению контента быть более открытым для интерпретации и туманным. Эта концепция будет обсуждаться подробнее во второй и последней статьях этой серии.

Mobile-First Updates для существующих сайтов

В настоящее время оптимизаторы, которые хотят обновить существующий веб-сайт, чтобы он оставался проиндексированным и актуальным после запуска Mobile-First Indexing, сталкиваются с простой проблемой: со всеми историческими возможностями мобильной разработки главное, что SEO-разработчики должны сделать, это сделать убедитесь, что мобильные устройства получают все необходимые инструкции по ранжированию и индексации, которые исторически были включены на страницы рабочего стола. Особенно это касается тегов заголовков, тегов описания, тегов href = lang, канонических тегов и разметки Schema.org; Он также включает в себя все теги OG и карты Twitter, ссылки на XML-карты сайтов и медиа-карты сайтов, инструкции роботов (on-page metas и robots.txt) и, возможно, даже ссылки на страницу политики конфиденциальности. В обоих случаях задача может также включать проверку связи веб-сайтов с активами конкретного приложения, такими как ссылки веб-сайтов на файлы ассоциаций приложений, так что глубокие ссылки могут быть проиндексированы и выполнены правильно.

Объем требуемой работы будет зависеть от того, как сайт исторически обрабатывал мобильный трафик. Если сайт в настоящее время построен в Responsive-Design, минимальные, если таковые имеются, изменения могут потребоваться. Тем не менее, если сайт все еще построен с отдельными мобильными URL-адресами на «м.» субдомен или если он использует выборочную, динамическую или адаптивную обработку для отправки контента на мобильные устройства, будет еще много работы, особенно с точки зрения различных версий контента. Лучшие инструменты для проверки отдельной страницы или шаблона Google Mobile-Friendly инструмент , а также Инструменты разработчика Chrome для просмотра исходного кода в симуляторах с помощью ' осмотреть элемент чтобы получить четкое представление о том, что может быть захвачено во время сканирования. Для крупномасштабного расследования SEO должны сильно опираться на информацию, которую они могут получить от Google Search Console и из таких инструментов, как Кричащая лягушка , которые позволяют сканировать сайт с помощью сканера Google для смартфонов, извлекая теги, которые необходимо проверять на каждой странице.

Для крупномасштабного расследования SEO должны сильно опираться на информацию, которую они могут получить от   Google Search Console   и из таких инструментов, как   Кричащая лягушка   , которые позволяют сканировать сайт с помощью сканера Google для смартфонов, извлекая теги, которые необходимо проверять на каждой странице

Chrome Dev Tools, Оценка адаптивного дизайна сайта: http://www.girliemac.com/blog/2016/08/16/developer-experience-matters/

Заключение

Google перешел от выпуска обновлений, которые создают значительные резкие изменения, к постепенному развертыванию всех изменений в течение определенного периода времени без серьезных сбоев. Их влияние может быть не столь очевидным, но Индексирование с мобильных устройств наверняка окажет глубокое влияние на SEO и остальную часть цифрового ландшафта с течением времени. Эта статья является первой в серии из трех статей, посвященной индексации с мобильных устройств. Эта статья была посвящена немедленным обновлениям, которые SEO должны учитывать в своей стратегии, чтобы поддержать существующий веб-сайт. Следующая статья этой серии будет посвящена большему влиянию, которое Индекс Mobile-First будет оказывать на стратегии SEO, и ощутимому сдвигу в сторону разрыв связей между URL-адресами, контентом и устройством, на котором представлен контент , Также будет обсуждаться алгоритмический сдвиг в сторону Schema, каналов и облачного хостинга. Заключительная статья этой серии будет посвящена новой группе вариантов сайтов Mobile-First, которые предпочитает Google, предположительно, чтобы помочь SEO-специалистам и веб-мастерам достичь сильной и долгосрочной индексации Mobile-First. Мир становится мобильным, и эти стратегии гарантируют, что ваши усилия по SEO могут идти в ногу!

Если вы хотите больше поговорить об индексации Mobile-First, обратитесь к Синди или Команда MobileMoxie ,