От: Синди Крум
В течение прошедшего или более года Google проводил тестирование различных моделей индексации и представления в результатах мобильного поиска в рамках перехода к индексации с мобильного устройства. Около месяца назад Google сделал объявление, в котором указывалось на возможные задержки с запуском Mobile-First Indexing; и если случайные комментарии на конференциях какие-либо признаки того, что происходит, кажется (несколько иронично), что Google может быть пытаются интегрировать результаты AMP в свой индекс Mobile-First , Тем не менее, они заверили всех, что Индекс Mobile-First должен появиться в конце этого года или в начале 2018 года. , Теперь, благодаря вводу-выводу Google через пару дней, те из нас, кто работает в «мобильном SEO», надеются получить больше ясности о будущем индексации с помощью Mobile-First.
Это третья и последняя статья в серии, посвященной индексированию на мобильных устройствах. Первая статья в серии дала некоторые справочная информация о мобильной индексации и как Google исторически определял рейтинг мобильного контента. Вторая статья изложена наша теория, что Mobile-First Indexing меньше об ограничении индекса Google для контента, удобного для мобильных устройств, и больше о межсистемном контенте, индексируемом в облаке. Мы предположили, что индексирование в первую очередь для мобильных устройств связано с уменьшением зависимости Google от URL-адресов как уникальных идентификаторов в их индексе; В нашей теории также сделан сильный акцент на пользу, которую видит Google, когда веб-мастера размещают контент в своем облаке.
Эта статья расширяет концепцию снижения индексации Mobile-First на URL, начиная с обсуждения того, что заменит URL в качестве уникального идентификатора в индексе Google, и того, как будущая архитектура Mobile-First будет полагаться на контент-API в качестве более эффективные средства поиска и индексации контента. В завершение будут описаны различные методы разработки приложений и веб-приложений, которые использует Google. Эти технологии имеют тенденцию полагаться на минимальную зависимость от URL-адресов и максимальную зависимость от каналов и API-интерфейсов, которые Google в последнее время поддерживает и продвигает в своих сообществах разработчиков.
Почему URL не идеальны для индексации
Чтобы понять взгляд Google на будущее, вы должны понимать, что Google считает, что будущее - это не мобильное, а искусственное интеллект / искусственное интеллект. В его Письмо учредителей 2016 года Генеральный директор Google Сундар Пичаи сказал: «Сначала мы перейдем с мобильного телефона на первый в мире ИИ». Он повторял это мнение в последующих выступлениях и заявлениях в течение года.
Этот акцент на ИИ важно помнить в контексте SEO, потому что ИИ зависит от быстрой обработки контента и отношений. Эффективный ИИ не может быть затруднен медленным сканированием веб-сайтов и URL-адресов. ИИ - это то, что позволяет чат-ботам вести содержательные беседы с людьми, помогать им получить то, что им нужно, и ни одна из этих вещей не требует веб-сайта или браузера, хотя для них требуется «сеть» в более общем смысле. Элементы AI из Интернета можно подключить к любому существующему веб-сайту, приложению или результату поиска. Благодаря голосовым возможностям и подходящему оборудованию, они также могут быть подключены к элементам Интернета вещей (IoT).
Чтобы Google смог разработать лучшую систему ИИ для машинного обучения, им нужен доступ ко множеству информации, а не только к статической информации; чтобы быть в курсе всего в реальном времени, им нужен доступ к огромным потокам информации, которые они могут обрабатывать в реальном времени. Эта информация поступает из баз данных и API, а не из URL. Google хочет вырезать посредников, которые, оказывается, являются URL-адресами.
Процесс сканирования и кэширования URL страниц за страницей Google замедляется из-за необходимости снова и снова получать доступ и игнорировать весь дизайн сайта и ориентированный на действие код в шаблоне страницы. До того, как сеть стала настолько огромной - когда веб-контент был статичным и генерировался медленнее - Google предпочитал ползать, искать новый контент. Но теперь веб-сайты стали более изощренными, и все движется от статического контента к индивидуализированному взаимодействию и уникальному контенту по запросу. Это делает зависимость от отдельных URL-адресов еще менее масштабируемой. Цель Google «организовать мировые данные» становится совершенно несостоятельной, когда вы понимаете, что 90% мировых данных было создано за последние два года. Поскольку сеть продолжает расти все более быстрыми темпами, сканирование как средство индексации контента со временем станет только неэффективным.
В то же время возросла способность Google использовать облачное хранилище и облачные вычисления, что меняет баланс эффективности: репликация и размещение целых баз данных теперь потенциально более эффективны, чем сканирование страниц, создаваемых базами данных. Для Google стало экономически выгоднее просто один раз кэшировать уровень представления и индексировать базу данных или напрямую подключаться к ней с помощью API - и в этом вся суть индексации. Этот процесс позволит Google меньше полагаться на URL-адреса для индексирования контента, но также заставит их становиться более зависимыми от таких вещей, как API, каналы XML, каналы JSON-LD и ServiceWorkers.
Отказ от индексации веб-контента, основанного только на URL-адресах, для Google весьма существенен. Они годами пытались свести к минимуму свою зависимость от ссылок в качестве сигнала для качества, но это изменение значительно продвигает эту цель. Помимо того, что не нужно просто подчеркивать алгоритмическое значение, которое один URL-адрес может разделять с другим URL-адресом посредством ссылок, он открывает возможность индексирования огромного количества веб-контента, который исторически невозможно было отобразить, поскольку он полагался на браузер для отображения URL-адреса. Все больше и больше людей получают доступ к веб-контенту с таких устройств, как Google Home и Amazon Echo, где становится очевидным ограничение только возможности открывать контент с помощью URL-адреса. Google знает, что для того, чтобы по-настоящему охватить взаимодействие между устройствами, они должны включать устройства без браузеров, а иногда даже без экранов.
Имея это в виду, все еще важно отметить, что этот сдвиг называется индексацией с мобильного устройства, а не только с мобильного. Ожидается, что существующие индексы, соответствующие базовому стандарту для мобильных устройств, останутся в индексе. Им просто придется конкурировать с дополнительным контентом, и есть шанс, что новому контенту, ориентированному на мобильные устройства, может быть предоставлено преимущество алгоритмического или аналогичного типа. Дело не в том, что URL-адреса будут исключены из индексации, а в том, что URL-адреса будут исключены в качестве предпосылок индексации.
Параметры индексации для мобильных устройств в Интернете:
Со всеми этими изменениями трудно понять, как сосредоточить усилия на разработке с учетом SEO. Более года назад Google начал внедрять и пропагандировать новые варианты разработки мобильных сайтов, которые кажутся особенно хорошо ориентированными на индексацию Mobile-First из-за их зависимости от каналов, API и хостинга Google. Многие из этих вариантов разработки уже, кажется, получают приоритет в результатах мобильного поиска, несмотря на то, что Google настаивает, что они не являются алгоритмически предпочтительными.
Пока Google не предоставит больше ясности, SEO могут рассматривать следующие стратегии развития в качестве вариантов по умолчанию для Mobile-First: Progressive Web Apps (PWA), страницы Progressive Web AMP (PWAMP), целевые страницы Google My Business и действия Google Assistant, подробно описанные ниже:
Прогрессивные веб-приложения: часто называемые просто PWA, это HTML5, насыщенные JavaScript веб-приложения, которые ведут себя как нативные приложения. Они доступны по веб-URL-адресам, но также включают возможность загрузки и добавления на домашний экран мобильного устройства, например, родные приложения. Когда пользователи «загружают» приложение, они действительно загружают файл метаданных приложения, который называется «Манифест приложения», и файл, называемый ServiceWorker. На практике ServiceWorker кэширует и настраивает контент для более быстрого представления и бесперебойного UX, похожего на приложение. В действительности же ServiceWorker разделен на две части: оболочка приложения, которая управляет шаблонами и режимами отображения PWA, для которой задано предварительное кэширование с использованием CacheAPI, и другая часть, которая контролирует, какие элементы содержимого базы данных должны кэшироваться. в локальном хранилище телефона, называется IndexedDB API ,
В автономном кэше базы данных хранится только уникальный текст, изображения и взаимосвязи структурированных данных, а оболочка приложения и сценарии действий хранятся в другой части ServiceWorker. Это гарантирует, что любой контент, который был просмотрен на устройстве ранее, может быть просмотрен снова, даже когда телефон находится в автономном режиме. (Google на самом деле имеет внутреннюю инициативу под названием Оффлайн-Первый Дизайн , которая фокусируется на подобных вещах.) Это отлично подходит для пользователей, но также отлично подходит и для Google, потому что теперь весь уникальный веб-контент легко доступен через API в формате JSON-LD, который Google, как следует из названия, может «индексировать». ' ServiceWorker по сути становится API для вашего сайта, где контент уже отделен от дизайна и помечен соответствующей схемой, поэтому Google знает, что это такое.
Мобильные приложения PWAmp. Многие разработчики, которые создают великолепные PWA, также используют код AMP, чтобы еще больше сократить время загрузки для еще большего удобства пользователей. Помните, что веб-мастера могут использовать код AMP HTML, CSS и JavaScript на любой странице, чтобы получить большинство преимуществ в скорости, даже если страницы никогда не предназначались для проверки. Это обновление кода позволяет разработчикам использовать AMP-ServiceWorker, что позволяет PWA работать в границах целевых страниц AMP, размещенных в Google, используя AMP URL AP I, который сопоставляет размещенные в Google URL-адреса AMP, которые Google обслуживает, с их исходными страницами AMP в основном домене. Это позволяет AMP-валидной странице PWAmp выступать в качестве дверного проема для остальной части веб-приложения, что позволяет лучше отслеживать и контролировать взаимодействие после начальной загрузки страницы.
Целевые страницы Google My Business: бизнес-часть Google+, которая называется Google My Business, уже отлично подходит для индексации с мобильных устройств. Это важно для бизнеса, который хочет контролировать свои результаты в запросах Google Maps и Google Local, для компаний, собирающих звездные рейтинги и обзоры, а также для основного способа продвижения местных рейтингов, особенно если у них нет веб-сайта. Поскольку контент, который вы отправляете в Google My Business, уже размещен в базе данных в облаке Google, ему не нужен API. Мы ожидаем, что Google может вскоре начать возобновлять свои усилия по продвижению взаимодействия Google My Business, потому что это соответствует их целям - дать возможность большему количеству людей использовать веб-контент без необходимости в разработчиках.
Общим для всех этих методов разработки является то, что они практически полностью отделяют контент от дизайна. Во всех случаях такая сегрегация позволяет Google более эффективно сканировать и индексировать контент без устранения уровня представления. Важно также то, что Google также облегчает становление уровня представления, как в случае ответов, карт, изображений и аналогичных результатов, которые часто всплывают наверх, когда они считают это выгодным. Учитывая это, не случайно, что последнее обновление Chrome было сосредоточено на улучшении кэширование контента для чтения в автономном режиме и последнее обновление Headless Chrome сосредоточены на том, чтобы не нуждаться в видимой оболочке интерфейса , Это также не случайно, что Chrome OS и Android OS становятся совместимыми , Различия между приложением и сетью исчезают, и Google хочет использовать свои активы на всех возможных платформах.
Важность Firebase и динамических ссылок
Firebase - это облачная база данных, которая уже около четырех лет входит в набор сервисов Google. Это было основным направлением во многих сессиях ввода-вывода Google в 2016 году, и, похоже, оно является центральным в планах Google по продвижению вперед, особенно в том, что касается индексации на мобильных устройствах. В прошлом году, сделав основной акцент на вводе-выводе Google, Google перенес большую часть документации по глубоким ссылкам и индексации приложений в новые места в https://firebase.google.com/ , В то время как документация и маркетинговые материалы по-прежнему кажутся разрозненными и иногда тупыми, общая цель платформы, по-видимому, заключается в том, чтобы позволить нативным приложениям и веб-приложениям беспрепятственно работать на множестве различных подключенных устройств, особенно Android Auto, Android TV, носимые устройства, Google Home и другие. элементы IoT.
Firebase позиционируется как платформа управления приложениями, которая обеспечивает облачный хостинг для вашего приложения и всего его содержимого. Он работает для PWA, поскольку они считаются «приложениями», но не работает для обычных веб-сайтов. В своей лучшей реализации он помогает веб-мастерам связывать экраны приложений Android с соответствующими экранами приложений iOS и / или следственным веб-контентом в PWA, так что три версии одного и того же контента могут быть проиндексированы и ранжированы вместе, а также взаимодействия пользователей по всему различные платформы могут быть отслежены и отнесены более точно. Важно отметить, что Firebase не поддерживает обычные мобильные сайты - только PWA. Это еще один сильный сигнал о том, что Google очень оптимистично смотрит на будущее PWA.
Полезным побочным продуктом интеграции Firebase является Dynamic Links, который позволяет веб-мастерам использовать одну ссылку для совместного использования фрагмента контента на любом устройстве, независимо от того, установлено приложение или нет. Динамические ссылки действуют как механизм устранения неоднозначности, направляя пользователей к нужному контенту на лету, не зная перед запросом, понадобится ли ему работать в приложении для Android, iOS или просто в Интернете. Вы можете вспомнить предшественника Dynamic Links, Google Goo.gl URL Shortner, который впервые запустил Now on Tap, но теперь ему снова дают новую жизнь в Firebase.
Хотя для работы динамических ссылок ресурсы Firefox не обязательно должны размещаться, это помогает. Есть четыре способа создания динамических ссылок включая ручную опцию и API, который может работать с динамическими ссылками iOS, что, вероятно, могло бы помочь с индексацией приложений iOS, хотя это не указано в документации. Документация Android явно отсутствует в объяснении, поэтому мы полагаем, что это может указывать на то, что Google автоматически переведет глубокие ссылки Android на динамические ссылки в ближайшем будущем или, возможно, после официального запуска индексации Mobile-First.
Динамические ссылки имеют значительный потенциал, чтобы изменить то, как мы взаимодействуем с приложениями на различных подключенных устройствах, особенно если Apple устранит существующие препятствия для интеграции iOS, которые обесценили индексацию приложений iOS в прошлом году (в частности, запрет на интеграцию SafariViewController в индексации приложений Google). SDK для любых приложений, представленных в App Store). Если Apple создает новые препятствия (как это было с SDK для индексирования приложений и SafariViewController), разработчикам iOS, возможно, придется убедить разработать две версии своего приложения для iOS - одну для отправки в App Store, а другую для интеграции с Firebase. С другой стороны, Google может убедить разработчиков iOS создавать свои приложения для интеграции с Firebase, предъявив требование о продолжении ранжирования в пакетах Google App, поскольку эти пакеты теперь отправляют значительный объем трафика в App Store.
Firebase также, по-видимому, является движущей силой Android Instant Apps, которая может предоставить альтернативный вариант для разработчиков приложений, особенно если iOS продолжает ограничивать интеграцию разработчиков приложений с Google. Благодаря приложениям Android Instant Google позволяет индексировать собственные приложения Android и запускать их прямо из облака в браузере без загрузки. В будущем Google может попытаться использовать технологию «Instant Apps», чтобы полностью отобразить нативное приложение из Интернета, даже если в Dynamic Link нет соответствующего веб-сайта или PWA. Они также могут попытаться запустить Instant Apps на устройствах iOS, чтобы сделать App Store неактуальным.
Параметры индексации для мобильных приложений для собственных приложений:
Фокус и рост Firebase важны, потому что исторически приложения создавали значительные препятствия для индексации Google. Они не построены на HTML и не живут полностью в сети, поэтому к ним не могут получить доступ обычные сканеры, которые просто имитируют веб-браузеры. Приложения изначально не имеют URL-адресов, но вместо этого полагаются на «схемы приложения», которые генерируют URI приложения для определения местоположения приложений или «экранов» в приложении. Они функционируют так же, как URL-адреса, но могут получать доступ только к контенту в коде приложения, а не в Интернете. Многие приложения теперь также загружают веб-контент, но это делается либо с помощью API в базе данных контента, либо с помощью кода «веб-просмотрщик», который позволяет приложению вести себя как браузер.
Как и в Интернете, новая стратегия индексации приложений, по-видимому, сосредоточена на размещении приложений в Google и отделении контента от дизайна, чтобы упростить доступ к контенту в виде канала или API. Следующие варианты должны рассматриваться как лучшие варианты разработки приложения Mobile-First:
Приложения для Android. Приложения Android с глубокими связями могут быть проиндексированы, но Google по-прежнему в значительной степени полагается на их связь с соответствующим веб-контентом для определения релевантности глубокой ссылки в результатах поиска. В прошлом году Google активно поощрял разработчиков Android обновлять схемы своих приложений на HTTP или HTTPS, а также обновлять URI схем приложений в соответствии с форматированием веб-URL соответствующего веб-сайта. Это позволяет URI приложения и веб-URL стать взаимозаменяемыми, упрощая Google сопоставление контента приложения с соответствующим веб-контентом. Приложения Android, настроенные с использованием этого типа глубоких ссылок, могут быть отсканированы и проиндексированы Google.
Приложения, использующие схемы HTTP или HTTPS, должны также включать API индексации приложений Google и файл сопоставления «Ссылки на цифровые активы», который связывает существующие веб-URL-адреса с содержимым приложения и размещается в корне домена. Этот файл сопоставления позволяет Google понять, какие веб-URL должны визуально указывать, и ссылаться на глубокую ссылку в результатах поиска Google, когда у пользователя установлено приложение. Как уже упоминалось выше, отсутствие документации об автоматизации создания динамических ссылок Android в Недавно обновленная документация Google (5/5/17), это подозрительно. Google, возможно, нашел способ автоматического создания динамических ссылок для приложений Android, и это может стать очевидным, если они объявят о слиянии между консолью Google Play и консолью Firebase в Google I / O на следующей неделе. Приложения Android, которые все еще используют пользовательские схемы (не HTTP, HTTPS или не отражающие веб-URL-адреса), также должны разметить соответствующие веб-страницы или карты сайта с помощью тегов rel = alternate, которые ссылаются на пользовательские URI.
Приложения для iOS. С середины 2015 года до середины 2016 года Google могла индексировать приложения iOS с помощью API-интерфейса для индексации своих приложений. Если бы это было все еще так, приложения для iOS были бы отличным вариантом для индексации с мобильного устройства. К сожалению, Google и Apple смогли сотрудничать в индексации приложений только на короткое время, пока механизм индексации приложений с Google фактически не стал основанием для блокировки или отклонения приложения из iTunes App Store. Приложения iOS включены сюда временно, поскольку, как описано выше, похоже, что Firebase может предложить новый механизм индексации приложений iOS через новый API, который генерирует динамические ссылки для пользовательских схем ссылок в iOS. Если это работает и может быть поддержано, это будет невероятно полезно для обеспечения полного выражения межсервисной природы индексации Mobile-First, но на основе грубой истории сотрудничества iOS и Google по этому вопросу и потенциального рынка. Подчеркнув, что Apple может проиграть, предоставив своим постоянным пользователям возможность интеграции и взаимодействия между устройствами, не относящимися к iOS, приложения iOS включены в этот список только временно.
Экраны приложений Private-Index: Android и iOS позволяют разработчикам приложений настраивать некоторые экраны приложений для «приватной» индексации, чтобы пользовательский поиск мог отображать экраны с личной информацией пользователя только для просмотра. В обоих случаях процесс включает в себя настройку приложений с глубокими ссылками и интеграцию их с API - для Android он называется API индексации приложений, а для iOS - CoreSpotlight. CoreSpotlight работает только для поиска в Siri, Safari или Spotlight. В iOS Google в настоящее время может получать контент Private Index только из семейства приложений Google и только тогда, когда пользователи входят в свою учетную запись Google, но маловероятно, что им когда-либо удастся найти другой контент приложения с глубокими связями, поскольку в настоящее время доступен только через родную Apple OS. Пользователи Android могут отображать в Google Now и в SERPS правильно размеченный контент Private Index для поиска в Google.
Мгновенные приложения для Android: Google также активно тестирует нативные приложения для Android, которые живут в облаке и не требуют установки для работы. Как правило, они не имеют веб-аналога, но индексируются с помощью глубоких ссылок в коде приложения, которые могут запускать небольшие части приложения непосредственно в браузере и, возможно, использовать динамические ссылки для индексации. Хотя процесс, обеспечивающий это, публично не описан, он представляется возможным благодаря облачному хостингу и динамическому связыванию в Firebase. Важной частью здесь является то, что этот процесс позволяет индексировать приложения без аналогов на веб-сайте. Неясно, как будет определен рейтинг контента этих мгновенных приложений, но вполне вероятно, что это будет комбинация сигналов, таких как схема, взаимодействие и видимый текст, похожих на веб, но без веб-ссылок. Если Google сможет сделать Instant Apps успешным, этот шаг будет иметь большое значение для создания магазинов приложений в прошлом.
Действия Google Assistant. Действия Google - это, по сути, слой интерактивной презентации, доступ к которому можно получить визуально или в виде серии устных вопросов. Два уровня представления предназначены для получения одних и тех же ответов, только по-разному. Утилита связана с API базы данных и способна выполнять простые команды внутри базы данных. Из-за требований к обоим уровням представления - визуальному и голосовому, они работают с браузером или без него и могут повысить ценность продуктов Google Home. Действия Google, похоже, создают взаимодействия, очень похожие на те, которые были временно доступны с помощью API Google Now, который исчез из публичного обсуждения около двух лет назад, вскоре после того, как они были впервые объявлены. Действия Google также могут рассматриваться как приложения для мгновенных приложений mini-Android, которые сочетают в себе голосовую совместимость. ChatBots являются неотъемлемой частью Google Actions и могут быть разработаны специально для использования в Google Actions или могут быть развернуты параллельно в Facebook Messenger, Twitter и Slack с помощью утилиты API.AI, как показано ниже.
Google не дал конкретных рекомендаций по оптимизации действий, кроме как предлагать их отправку в домашний каталог Google. Тем не мение, Похоже, что действия смогут ранжироваться в мобильных и настольных поисковой выдаче, как вы можете видеть в примере OpenTable ниже. Поскольку уровень представления Google Action может ранжироваться непосредственно в поисковой выдаче, Google Actions работают как индексируемые порталы в функциональности приложения или веб-сайта. Они имеют метаданные, как и приложения Android, и полагаются на просматриваемый код JSON, который основан на понимании сущностей на основе разметки схемы JSON-LD.
Хотя Схема действий и Действия Google еще не кажутся неразрывно связанными между собой, они могут появиться в будущем. Схема действий существует уже некоторое время, но разметка часто встраивается в HTML страниц или электронных писем, а не форматируется как JSON-LD в заголовке документа или в отдельном файле в целом, где схема, кажется, выглядит направился сейчас. Здесь важно отметить, что действие OpenTable - это первый результат в нулевой позиции. Как и другие материалы с нулевым положением, такие как График знаний, Ответы, Карты, Изображения, Видео и Результаты покупок, Действия размещаются в Google и используют API для взаимодействия с базами данных, которые контролируют их содержимое.
Мы предполагаем, что Google начнет стимулировать веб-мастеров переводить свои веб-сайты в PWA, соблазняя их улучшенным отслеживанием между устройствами, бесплатным размещением баз данных или ресурсов и улучшенной способностью отслеживать и управлять сбоями. Они также сосредоточат свои сообщения на значительных улучшениях в привлечении пользователей и конверсии, которые статистически дают PWA, а также на снижении зависимости от данных, увеличении скорости и способности работать в автономном режиме. После того, как веб-контент настроен как PWA, веб-мастерам, вероятно, будет намного проще упаковывать и переупаковывать контент в разные действия Google или перетаскивать элементы контента в другие приложения, такие как Android Auto, с минимальными усилиями или при участии разработчиков.
Как мобильная индексация может принести пользу всем нам в будущем
Важным является переход к веб-приложениям, которые постоянно взаимодействуют с сервером на основе отдельных фрагментов контента, а не одной полной страницы / URL-адреса за раз, и могут иметь жизненно важное значение для перехода Google к индексации с мобильного устройства. Google стремится приспособиться к этой новой модели разработки, поскольку она обеспечивает более персонализированный пользовательский интерфейс с более быстрым временем загрузки. Это также делает такие вещи, как машинное обучение в стиле больших данных, и ответы AI намного проще.
Люди любят приложения, но им сложно управлять и разрабатывать, а проблемы разработки часто ограничивают маркетинг и продвижение, которые могут выполнять компании. Однако, как только контент полностью отделен от уровня представления, эти проблемы сводятся к минимуму. Google рассматривает Firebase как путь вперед, и вскоре он может стать критически важным для управления ранжированием и маркетингом, ориентированным на мобильные устройства. Он обеспечивает большую часть управления приложениями и конфигураций в облаке и, в свою очередь, обеспечивает возможность создания отчетов и настройки приложений в режиме реального времени. В этой системе также размещается контент, что делает ненужным непрерывное сканирование.
Существуют также слабые сигналы о том, что Firebase также может использоваться для управления новыми домашними устройствами или другими элементами подключенного дома, что придаст платформе еще большую маркетинговую и аналитическую силу. Но Интернет вещей (IoT) создал потребность в большем количестве голосовых продуктов, поэтому активы, такие как ChatBots, которые используют AI или просто облегчают сбор данных AI, будут важны для многих компаний. Google видит будущее и считает, что этот переход к индексированию с мобильных устройств является важной частью этого процесса, и мы склонны с этим согласиться.
