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

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

Большинство из нас в цифровом пространстве слышали статистику о том, что 90% мировой информации было создано за последние два года. Это отличная иллюстрация огромной задачи, стоящей перед Google для достижения цели каталогизации всей мировой информации. Они добились значительного прогресса, но определение «информация» расширяется. «Информация», по словам Google, теперь включает в себя: песни, фильмы, телешоу, приложения, рецепты, книги и все, что вы только можете придумать. Google хочет знать не только то, что информация существует, но именно то, чем она является, и как получить к ней доступ и представить эту информацию на различных устройствах и в различных форматах, не ограничиваясь только визуальным представлением в браузере.

Достаточно сказать, что сканирование интернета для индексации и ранжирования становится гораздо более сложной задачей. Когда компании добавляют новый контент, они не удаляют старый контент. Кроме того, Google обусловил нас настороженно относиться к удалению контента с наших сайтов, предположительно потому, что поддержание архива лучше для пользователей, но также и в том случае, если у старого контента есть ссылки, социальные сети или другие сигналы, которые помогают ему продолжать движение движение. Чтобы не отставать от постоянно растущего объема цифрового контента, который Google хотел бы организовать, им нужно будет сделать свой процесс более эффективным и более жестко ограничивать свои алгоритмические оценки. Они уже указали на сильное предпочтение сортировке сигналов, таких как схема и другие микроформаты, потому что это упрощает сканирование, уменьшает алгоритмические усилия и сводит к минимуму накладные расходы, необходимые Google для продолжения индексации и ранжирования контента. Теперь, с Mobile-First Indexing, такие факторы станут еще более важными.

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

Потеря URL как основы индексации

Исторически SEO говорили об индексации в несколько бинарных терминах: контент был в индексе или нет (или когда-то контент был в мобильном индексе, настольном индексе или ни того, ни другого). При SEO-аудите могут возникнуть технические проблемы, когда в индекс добавлено слишком много или слишком мало страниц. Опять же, вопрос о том, что есть или нет в индексе. Как SEO мы до сих пор редко задавались вопросом, как работает индекс. Изменение, которое Google описывает переход к индексации с мобильного устройства, на самом деле заключается не в том, как что-то разрешено или запрещено для включения в индекс Google, а в том, как все организовано в индексе. Предполагая, что это так, Google использует слово «индекс» для обозначения «организовать», а не просто «идентифицировать», поэтому это изменение может быть даже более значительным, чем понимают большинство SEO-специалистов.

Индекс Mobile-First ссылается на будущее, которое будет в меньшей степени зависеть от URL-адресов в качестве организационного механизма индекса Google. Вы должны понимать, что индексы - это просто базы данных. До того, как все было оцифровано, телефонная книга представляла собой алфавитный указатель людей, а белые страницы были алфавитным указателем компаний, предварительно отсортированных по категориям. Аналогично, десятичная система Дьюи представляла собой указатель книг, которые присутствовали в библиотеке, упорядоченные по номерам. Книги могут быть в индексе, а не в индексе или неправильно проиндексированы. Важно то, что индексы не являются общедоступными; у них есть объединяющий организационный принцип, основанный на элементе, который извлекается из большего набора данных, таких как имя, заголовок, категория или числовое представление.

Google использовал URL-адреса и структуру URL, а также метаданные и ссылки для организации контента в своем индексе, поэтому SEO всегда работали с максимальным «одним URL на каждую часть контента». Google всегда был «поисковой системой в Интернете», и интернет в основном используется через веб-браузеры, которые используют URL-адреса, но все меняется. Интернет на самом деле намного больше и содержит гораздо больше информации, которую нельзя представить в браузере. Огромные объемы данных и информации, которые не отформатированы в HTML, обрабатываются в фоновом режиме Интернета. Этот тип информации становится критически важным для вычислений Интернета вещей (IoT) и стиля больших данных. Он доступен только через API и прямой доступ к базам данных, и Google хочет иметь возможность использовать эту информацию в своем алгоритме.

Кроме того, мобильные операционные системы (ОС) и браузеры становятся менее четкими. И Spotlight Search, и Google Now on Tap - это аспекты мобильной ОС, которые могут искать и открывать контент из Интернета и приложений. В случае Google Now on Tap кажется, что контент предоставляется в фидах и API, без необходимости включать веб-страницу или URL. После того, как требование к URL удалено, контент из приложений может конкурировать с веб-сайтами, что делает его гораздо более удобным и гибким в плане того, как и где информация может быть представлена ​​пользователю. Менталитет Mobile-First Indexing позволяет Google дальше дистанцировать ранжирование от простых URL-адресов и ссылок и уделять больше внимания вещам, важным для мобильных устройств, таким как скорость, рендеринг и вовлеченность.

Многие из новейших технологий разработки, ориентированных на мобильные устройства, которые Google защищает, на самом деле запутывают или преуменьшают важность URL-адресов, структуры сайта и ссылок. Такие вещи, как собственные приложения, веб-приложения, PWA и AMP, скрывают доступ Google к URL-адресам и ссылочным данным. Контент AMP не имеет традиционных URL-адресов, но вместо этого живет на URL-адресе, который генерирует и размещает Google, и ожидается, что Android Instant Apps, только что вышедшие из бета-версии, будут такими же. Индексирование в приложении, глубоко связанные URI - это просто закладки в пользовательском потоке приложения. Аналогично, PWA использует постоянную связь с сервером для доставки контента, когда он запрашивается, и разные URL-адреса не нужны для запуска другого контента.

В течение многих лет Google пытался дистанцировать рейтинги от созданной им экономики ссылок, и теперь они, похоже, активно пытаются помешать SEO и веб-мастерам (или, возможно, им самим) полагаться на URL-адреса как основной организационный принцип в своем индексе. , Вместо этого Google, вероятно, начал связывать определенные индексируемые фрагменты контента с такими сигналами, как схема, структурная разметка на странице и каналы XML.

Схема, разметка и XML-каналы

Схема и вложенная схема уже несколько лет входят в число лучших рекомендаций Google для SEO, поскольку они помогают обеспечить конкретное и простое понимание сущности содержимого страницы. С тех пор как Google запустил обновление Hummingbird, которое сосредоточилось на сущностях, голосовом поиске и семантическом понимании, Google не так активно общался о поиске сущностей, но с подключенным домом он снова станет жизненно важным. Схема намного проще для Google сканировать и понимать, чем обычный HTML, и с переходом на JSON-LD она стала еще быстрее, потому что она отделена от кода страницы и доступна непосредственно с сервера. Google настолько заинтересован в Schema, что теперь они даже просят добавить определенные виды Schema в приложение. Это само по себе довольно показательно.

Переход от JSON к JSON-LD важен для более глубокого понимания Google мира. «LD» в «JSON-LD» означает «связанные данные», потому что JSON-LD не относится к отдельным частям метаданных, а вместо этого - к метаданным в контексте других метаданных. JSON-LD.org объясняет, что: Связанные данные расширяет возможности людей, которые публикуют и используют информацию в Интернете. Это способ создания сети стандартизированных, машиночитаемых данных через веб-сайты. Он позволяет приложению запускаться с одного фрагмента связанных данных и переходить по встроенным ссылкам на другие фрагменты связанных данных, размещенные на разных сайтах в Интернете ». Именно так Google планирует построить более глубокое понимание контента и отношений с контентом, не полагаясь на него. на ссылки и URL-адреса.

Google напрямую запрашивает информационные каналы из большего числа источников. Большинство компаний рады этому, потому что прямая подача информации в Google имеет прямые преимущества, такие как визуальная информация о погоде AccuWeather, которая отображается в верхней части результатов поиска, связанных с погодой, или рейсы и отели, которые Google легко обнаруживает в своих механизм агрегации или любой из миллиона продуктов, которые Google включает в PLA Google Shopping. Эти каналы дают Google именно ту информацию, которая им нужна, в том формате, в котором они хотят, чтобы ее можно было добавить непосредственно в вашу базу данных и отобразить соответствующим образом. Результаты из этих источников, похоже, оказываются предпочтительными в результатах мобильного поиска - потому что они обеспечивают хороший пользовательский опыт, а также потому, что их легко анализировать и отображать в Google.

Многие оптимизаторы могут не осознавать, что Google также использует XML-каналы и данные JSON-LD для получения списка карт с глубокими ссылками для индексации приложений, для понимания отношений Schema на большом подробном веб-сайте и для понимания таких вещей, как спортивные результаты, новости, рецепты и т.д. времена кино. Подобные методы превосходят старомодное сканирование, потому что они намного более эффективны. В обоих случаях веб-мастера по сути подключают вашу базу данных к Google API.

Mobile-First действительно означает Cloud First

Google также будет в значительной степени полагаться на свой собственный облачный хостинг для облегчения индексирования Mobile-First. Они называют это изменение индексированием Mobile-First, но это, вероятно, неправильно. Якобы, в более долгосрочной перспективе это более точно описывается как индексация «сначала на устройстве» или даже «сначала на облаке». Кажется, что почти каждое новое объявление Google - это еще один прием или уловка, чтобы заставить веб-мастеров размещать свой контент на серверах Google. Даже Google Play активно поощряет разработчиков приложений Android тестировать размещение своих приложений на облачной платформе Google, чтобы пользователи могли получить выгоду от более быстрой работы с собственными приложениями, как показано справа. Хотя это не является обязательным сейчас, вы можете ожидать, что облачный хостинг с Google будет сильно стимулирован или даже потребуется в будущем.

Google будет вкладывать все больше и больше ресурсов в свое облако, поскольку это позволит им уменьшить свою зависимость от сканирования и улучшить понимание того, как пользователи взаимодействуют с контентом с течением времени. В облаке, без использования URL для индексации, индексируемым контентом может быть текст, видео, аудио, изображения или что-либо еще; концепция, блестяще проиллюстрированная в твиттере Эмили выше. Поскольку стоимость облачного хостинга продолжает снижаться, а объем хранимых данных продолжает увеличиваться, преимущества, которые Google может ожидать от подталкивания разработчиков и веб-мастеров к размещению контента в их облаке, становятся очевидными. Облачный хостинг значительно улучшит способность Google управлять своей собственной эффективностью и минимизировать накладные расходы на их бизнес, но он также учитывает менталитет Big-Data, который они любят и который в долгосрочной перспективе может принести существенную прибыль. Вот основные понятия, связанные с облачным хостингом Google:

Меньше сканирования : хостинг гораздо эффективнее и эффективнее сканирования. Сканирование может быть наименее эффективным и наиболее сложным аспектом ранжирования в Интернете, и его трудно масштабировать. Если Google размещает ваш контент, им не нужно сканировать его так агрессивно, потому что они сразу же узнают, когда вы делаете обновления или загружаете новый контент. Они также могут использовать частоту запросов контента в своей системе, чтобы узнать, что является популярным, а что нет. Это лучшая мера взаимодействия, чем ссылки.

Более эффективный сбор и представление данных. Когда весь ваш контент находится в облаке Google, он может быть очень быстрым все время. Они используют свои собственные алгоритмы сжатия и кэширования; они также могут определять скорость устройства, запрашивающего контент, а затем адаптировать то, что они отправляют, в соответствии со скоростью сетевого подключения и устройства, к которому они подключены, поэтому контент работает на разных устройствах и в разных операционных системах без проблем.

Более быстрая презентация, которую Google получает от облачного хостинга веб-мастеров, принесет пользу пользователям Google, когда они получат доступ к размещенному в облаке содержимому, но также принесет пользу Google. Как показано на диаграмме ниже, Google предпочитает включать расширенные визуальные элементы, когда они могут непосредственно в поисковой выдаче. Они особенно важны для улучшения работы пользователей мобильного поиска и привлечения пользователей к результатам поиска. Когда Google размещает контент, он также позволяет Google быстрее и проще представлять ваш контент непосредственно в поисковой выдаче, как это. Google уже стимулирует такое сотрудничество с топ-рейтингами, особенно в результатах поиска на мобильных устройствах.

Гибкость контента. Частью создания контента, индексируемого в мире между устройствами или облаками, является более глубокое отделение контента от его «уровня представления предполагаемых устройств», что делает его независимым от устройства и даже потенциально независимым от формата. Когда чистый, необремененный контент может быть сохранен в базе данных, размещенной в Интернете, разработчики могут сосредоточиться на создании пользовательских интерфейсов для различных потенциальных устройств и форматов представления без необходимости постоянно копировать контент для каждого устройства - это немного похоже на концепция отделения контента от дизайна с помощью CSS, чтобы включить формат и функциональность, а не только визуальные подсказки для презентации.

Если Google придется сканировать и индексировать контент, привязанный к конкретным устройствам снова и снова для каждого устройства, индексировать и ранжировать его все, это было бы кошмаром. Облачный хостинг, независимый от контента, гораздо более масштабируем для ресурсов индексации Google, но также и для ресурсов внутри компаний. Google будет необходимо знать, какой контент должен быть хорошо ранжирован для каждого устройства, но с ростом числа потенциальных поисковых устройств растет число потенциальных вариантов использования.

Понимание индексации будущего

Трудность с отключением контента от соответствующего URL-адреса заключается в потере уникального идентификатора для индекса. URL-адреса в Интернете работают как SKU продукта в базе данных инвентаризации - существует соотношение один к одному. Итак, как Google будет управлять своим индексом без URL? Лучший ответ - это, скорее всего, реляционная база данных с пониманием сущностей и ИИ. У Google по-прежнему будут URL-адреса, которые в настоящее время есть в индексе, и они, несомненно, уже использовали их, чтобы начать создавать понимание сущностей для всех компаний и контента в текущем веб-индексе. Они могут объединяться со схемой из Интернета и другой информацией, которая у них есть, из контента, который они размещают на своей платформе облачного хостинга, и тогда их будет много. Оттуда Google может структурировать свое понимание на основе того, что он знает о мире в целом, используя Freebase / WikiData, которые они технически «удалили» несколько лет назад, но, возможно, на самом деле только что были переопределены. Возможно теперь, вместо того, чтобы быть созданным человеческими редакторами, это было построено Ранком-Мозгом.

Уже могут быть признаки этого появления в поиске Google, поскольку они пытаются устранить неоднозначность широкого запроса, который может означать две разные вещи. Как вы можете видеть ниже, Google считает, что запрос «Хлеб» может касаться двух очень разных тем: еда или группа. Вы знаете, что они понимают это слово, потому что вы можете увидеть предложения по устранению неоднозначности непосредственно в верхней части параметров поиска и предложения. Вы должны понимать, что каждый из этих вариантов устранения неоднозначности существует, потому что они оба относятся к очень конкретной информации в Графе знаний Google. Хлеб с едой связан с определенными ингредиентами, рецептами, изображениями, подсчетом калорий и тому подобным, в то время как с хлебом группа ассоциируется с песнями, датами гастролей и очень разными картинами. (Возможно, частью механизма распознавания изображений Google было помочь сортировать изображения по таким запросам!)

Заключение

Интернет меняется. По мере того как технология расширяется и совершенствуется, она становится все более и более невидимой. По мере того, как все больше наших ежедневных устройств подключаются к сети, они становятся менее зависимыми от экранов, браузеров и клавиатур прямого ввода, и вместо этого все они управляются удаленно из облака. Как Amazon Echo, так и Google Home позволяют вам контролировать элементы вашего дома, подключенные к сети, и выполнять простой поиск, используя только свой голос, и они отвечают на основе потоков данных из облака. Эти устройства могут работать и работают без использования URL-адресов, поэтому Google также должен начать работать в более независимой от презентации форме. Наши устройства перестают нуждаться в браузерах, поэтому индекс Google не должен быть организован по URL.

Со структурированными данными, особенно в JSON-LD, XML-каналах и API-интерфейсах, Google формирует глубокое понимание мира, который в меньшей степени зависит от URL-адресов для организации и оценки данных. Помимо этого, Google будет продолжать подталкивать разработчиков и SEO-специалистов к использованию своих услуг облачного хостинга часто бесплатно, поскольку это дает им такую ​​значительную выгоду в их способности индексировать свой контент. С большим количеством контента в облаке Google, Google всегда будет знать, когда контент обновляется, потому что его журналы сервера будут отображать его и автоматически инициировать повторное сканирование. Хостинг контента также позволяет Google понять больше об участии пользователей; Когда они размещают всю информацию о приложении, они могут точно знать, какой контент был запрошен с сервера, даже если не было запрошенного URL новой страницы, как это может случиться в PWA. Это более глубокие данные о взаимодействии, чем когда-либо раньше у Google!

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

Теперь, когда мы находимся в сегменте 2 из 3 по индексации Mobile-First, если у вас есть вопросы или вы хотите обратиться, вы можете найти Синди & MobileMoxie команда в твиттере.

Похожие

Комментарии