Какова политика Google в отношении отдельного контента по одним и тем же URL-адресам в версиях для мобильных и настольных компьютеров?


8

В настоящее время я разрабатываю мобильную версию своего сайта, где устройства пользователей автоматически идентифицируются, а затем отображаются либо мобильные, либо настольные представления с одним и тем же URL.

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

  • Как такое соглашение повлияет на мнение Google о моем сайте?
  • Это вредно для моего рейтинга?
  • Или Google разделяет результаты поиска на рабочем столе и на мобильном устройстве?

Ответы:


3

Похоже, вы обеспокоены тем, что передача контента для мобильных пользователей, отличного от пользователей рабочего стола по одному и тому же URL-адресу, с использованием обнаружения пользовательского агента может рассматриваться как форма маскировки и, таким образом, наказывается Google.

Согласно Центральному блогу Google для веб-мастеров , это не тот случай, если вы правильно обнаружите мобильный браузер. По сути, важно понять, что сканеры Google используют разные строки пользовательских агентов в зависимости от того, ожидают ли они контент для ПК или мобильных устройств. Например, типичная строка user-agent для обычных запросов Googlebot будет выглядеть так:

Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)

тогда как для запросов от мобильного сканера вы увидите что-то вроде:

SAMSUNG-SGH-E250/1.0 Profile/MIDP-2.0 Configuration/CLDC-1.1
UP.Browser/6.2.3.3.c.1.101 (GUI) MMP/2.0 (compatible; Googlebot-Mobile/2.1;
+http://www.google.com/bot.html)

или (для запросов смартфона):

Mozilla/5.0 (iPhone; CPU iPhone OS 6_0 like Mac OS X) AppleWebKit/536.26
(KHTML, like Gecko) Version/6.0 Mobile/10A5376e Safari/8536.25 (compatible;
Googlebot/2.1; +http://www.google.com/bot.html)

До тех пор, пока вы убедитесь, что правильно определяете запросы Googlebot последнего типа (а не первого типа) как мобильные, и обслуживаете их мобильным контентом, все должно быть в порядке. По сути, важно то, что обычные запросы робота Google должны получать контент на рабочем столе, в то время как запросы мобильного робота Google должны получать контент для мобильных устройств.

Вот хорошая диаграмма, иллюстрирующая это, из статьи Центрального блога Google для веб-мастеров, на которую я ссылался выше:

схема

Кроме того, чтобы сканер Google знал, что для мобильных браузеров может быть другой контент, вам нужно настроить свой веб-сервер так, чтобы он отправлял Vary: User-Agentзаголовок HTTP для любых страниц, для которых вы используете обнаружение агента пользователя . Вы также должны избегать распространенных ошибок при обнаружении пользовательских агентов .


8

Лучший способ действий - использовать канонические URL . Это позволяет избежать ситуации, когда вы будете оштрафованы за дублированный контент.

Когда речь идет о настольных и мобильных сайтах, большинство сайтов будет иметь что-то подобное на своем мобильном сайте:

Пример для: http://m.mywebsite.com/page.html

<link rel="canonical" href="http://mywebsite.com/page.html" />

Канонический тег в основном говорит Google, что один и тот же контент может быть доступен через несколько URL-адресов.

Пользователи Desktop / Mobile обнаруживаются сервером и перенаправляются на соответствующую версию (это происходит в Blogger, которая принадлежит Google).

С помощью этого метода Google не будет разделять результаты (вы не хотите этого). Это также означает, что входящие ссылки на мобильные страницы возвращают вес / «сок ссылок» на исходную страницу. В этом случае ссылки на http://m.mywebsite.com/page.htmlбудут влиятьhttp://mywebsite.com/page.html


7

По моему опыту, мобильные посетители хотят того же контента, что и посетители вашего рабочего стола. Я работал на туристическом сайте с большим количеством информации об отелях и ресторанах. Сайт обычно известен гостиницами, но мы думали, что мобильные пользователи будут гораздо больше заинтересованы в содержании ресторанов, потому что они ищут что-то, когда они отсутствуют. Это предположение было неверным, мобильные пользователи искали контент отеля так же, как и пользователи компьютеров.

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

  • Задержка является более важной проблемой, чем скорость загрузки на мобильном устройстве. Большие страницы не проблема, но каждый запрос может занять несколько секунд. Часто имеет смысл размещать больше контента на странице и позволить пользователю прокручивать его, а не заставлять их переходить на другие страницы.
  • Вес содержимого часто уменьшается из-за веса разметки, CSS и JavaScript. Начните с того, что пользователь не видит при попытке удалить байты со страницы.

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


1
«Пользователи, как правило, расстраиваются, когда не могут использовать мобильный сайт так, как они используют сайт для настольных компьютеров», - полностью согласен
krokola

@ Стефан, что вы подразумеваете под латентностью? В чем причина этого?
AgA

Задержка - время поездки туда и обратно. Время, которое требуется пользователю для инициирования действия, пока он не получит подтверждение этого действия от сервера. Задержка довольно нормальная, когда в телефоне есть Wi-Fi, но гораздо выше, когда он подключен к интернету через сотовую вышку.
Стивен Остермиллер

3

Вы можете отобразить мобильную версию, используя канонические и относительные альтернативные теги, настольную версию с альтернативным тегом и мобильную версию с каноническим тегом. При подаче динамического HTML по одному и тому же URL вы должны использовать HTTP-заголовок var.

Google объясняет это подробно:

https://developers.google.com/webmasters/smartphone-sites/details


1

Google достаточно умен, чтобы обнаружить мобильные и немобильные сайты. И комментарии конкретно, что это не рассматривается как спам.

Более важное соображение - пометить предпочитаемый вами URL как канонический.

Из Google WMT:

Дублированный контент обычно относится к существенным блокам контента внутри или между доменами, которые либо полностью совпадают с другим контентом, либо заметно схожи. По большей части, это не обманчиво по происхождению. Примеры не злонамеренного дублированного контента могут включать:

Discussion forums that can generate both regular and stripped-down pages targeted at mobile devices
Store items shown or linked via multiple distinct URLs
Printer-only versions of web pages

Это было хорошо задокументировано с 2010 года.

Смотрите статью SEL на:

Не наказывайте себя: мобильные сайты не дублируют контент

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

Как требуется дублирование контента (сроки и условия и т. Д.)

И, наконец, ознакомьтесь с темой инструментов Google для веб-мастеров:

Дублированный контент

Также у SEOMOz есть отличная статья на эту тему:

Что такое дублированный контент


0

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

Google распознает три разные конфигурации для создания мобильных сайтов.

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

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.