Международный SEO: когда альтернативный, hreflang и канонический сожительство ...

  1. Хорошо, каков план действий?
  2. Этап II: внедрение rel alternate и hreflang для обозначения языковых и страновых вариаций
  3. Фаза III: альтернативная версия предназначена не только для языков или регионов!
  4. Бинго! Зеленые флаги вернулись ;-)
  5. Полезность sitemap.xml
  6. Бонус: стратегии перенаправления путем обнаружения «агента пользователя» (с рабочего стола на мобильный...
  7. Перенаправляет через .htaccess против HTTP-заголовка
  8. Соответствующий синтаксис и в соответствии с рекомендациями Google
  9. Обнаружение агента пользователя (в PHP) с помощью класса Mobile_Detect
  10. В заключение и идти еще дальше ...

Это обсуждение с другом @david_libert на последнем SMX Paris, который побудил меня поцарапать этот пост. Мы обсуждали, насколько сложно «технически» управлять многоязычным сайтом, который может расти в геометрической прогрессии. Представьте себе следующий сценарий: электронный торговец, который хочет отказаться от своего сайта на нескольких языках, в нескольких валютах и ​​чьи продукты также доступны в нескольких цветах, все на сайте, предлагающем своим посетителям версию для мобильных устройств по URL-адресам. отдельные субдомены (с прозрачным перенаправлением на эквивалентные страницы). Горячий впереди !!!

@david_libert

Разумеется, речь пойдет об управлении каноническими атрибутами rel alternate и hreflang rel с намеком на перенаправление. Мы обсудим дублированный контент, DUST, почти дубликаты и, конечно, управление языками, странами и валютами. Все это смешанное, извращение гарантировано ^^
100% техническая тема, 100% практичность, 100% SEO!

Чтобы проиллюстрировать эту статью и довести сложность до ее кульминационного момента , я буду полагаться на вымышленный сайт электронной коммерции, добровольно минималистский, который имеет 2 страницы: домашнюю страницу -forcément- и страницу продукта, 2 URL-адреса в начале . По мере продвижения мы будем усложнять структуру URL-адресов различными параметрами, пока не получим абсолютно неусвояемую архитектуру для движков. Во второй части статьи мы сосредоточимся на том, чтобы сделать всю эту кашу URL полностью оптимизированной для SEO.
Go!

Наши 2 стартовых URL:
Наши 2 стартовых URL:

Простой.

Издатель сайта не намерен довольствоваться французским рынком. Он голоден, хочет получить долю на рынке и хочет расширить свою деятельность на Швейцарию и Германию. Предполагая, что языком по умолчанию является французский, он заканчивается URL-адресами, разбитыми следующим образом:

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

Мы переходим к 4 URL.

Поскольку используемая CMS не является гипероптимизированным уровнем SEO, появляются URL-адреса в DUST («Duplicate URL Same Text»):

легенда:
легенда:

легенда:

5 URL ... и снова я упростил для DUST, это часто намного хуже в реальности.

Таким образом, у нашего интернет-магазина 3 страны и 2 языка . Кто говорит, что электронная коммерция говорит деньги, и в нашем примере Швейцария играет в спор ;-) Они не хотят евро (и мы можем понять). Короче говоря, издатель хочет отображать разные валюты в зависимости от целевых стран. CHF для Швейцарии, евро для Франции и Германии. Кроме того, наш издатель является опытным маркетологом, и он также получит выгоду от «контент-маркетинга», ориентированного на страны (а не на языки). По умолчанию сайт отображает валюты в евро и ориентируется на Францию. Затем мы получаем:

Есть франкоязычная Швейцария и немецкоязычная Швейцария, то есть два языка для одной и той же страны, с акцентом на маркетинг и определенной валютой (CHF).

Есть франкоязычная Швейцария и немецкоязычная Швейцария, то есть два языка для одной и той же страны, с акцентом на маркетинг и определенной валютой (CHF)

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

Иди, иди Мориса, толкни вилку еще дальше! Предположим теперь, что продукт существует в 2 версиях: белом и черном . Вы, конечно, найдете его немного искаженным, но ничего особенного ... Белый цвет продукта является цветом по умолчанию и не генерирует параметр URL. Это дает нам что-то вроде этого:

С 3 мы перешли на 13 URL! И в качестве бонуса, дублированный контент (DC) затопляет сайт, предполагая, что цветовые вариации не заслуживают выделенной страницы (изменяется только изображение).

Я опускаю ноготь: наш издатель полон здравого смысла. Он знает, что мобильный трафик опережает настольный, и мы должны предложить подходящую версию. Адаптивный веб-дизайн не был сохранен в пользу отклонения сайта в поддомене (мы не обсуждаем, это так):

Адаптивный веб-дизайн не был сохранен в пользу отклонения сайта в поддомене (мы не обсуждаем, это так):

Бим 26 URL-адресов Бим 26 URL-адресов! Это становится извращенным, а? Я избавляю вас от версий URL с и без "www", https и т. Д.
С уважением, не думайте, что это карикатурно, наоборот! Это почти обычное место, подобные сайты я часто встречаю в своем районе. Не говоря уже о CMS, такой как Drupal, например, которая может создавать ужасное количество URL в таком контексте.

Сайт «Би-Пейдж» теперь погрузился в хаос и глубины Google. Да, робот-робот не знает, куда обратиться , тратит меньше, а «сок» полностью разбавлен. Наш издатель упал, потому что он столкнулся с реальной проблемой SEO, которая требует хорошего технического мастерства. Справочник воскресенье тоже в капусте. С этим, если мне скажут, что SEO мертв ...

Хорошо, каков план действий?

Фаза I: Имплантация канонического текста для уничтожения дублированного контента

Следует отметить, что канонический rel должен быть распространен на все URL сайта, а не только на те, которые генерируют DC или DUST.

Давайте на время отложим мобильные URL-адреса, которые получат определенную обработку. С реализацией канонического rel это дает, что:

  1. domaine.fr
    <link rel = "canonical" href = "http://domain.com/" />
  2. domaine.fr/index.html
    <link rel = "canonical" href = "http://domain.com/" />
  3. domaine.fr/index.html?pays=ch
    <link rel = "canonical" href = "http://domain.fr/index.html?pays=ch" />
  4. domaine.fr/index.html?lang=de
    <link rel = "canonical" href = "http://domain.fr/index.html?lang=de" />
  5. domaine.fr/index.html?lang=de&pays=ch
    <link rel = "canonical" href = "http://domain.fr/index.html?lang=de&pays=ch" />
  6. domaine.fr/produit.html
    <link rel = "canonical" href = "http://domain.com/product.html" />
  7. domaine.fr/produit.html?pays=ch
    <link rel = "canonical" href = "http://domain.com/product.html?pays=ch" />
  8. domaine.fr/produit.html?lang=de
    <link rel = "canonical" href = "http://domain.com/product.html?lang=de" />
  9. domaine.fr/produit.html?lang=de&pays=ch
    <link rel = "canonical" href = "http://domain.com/product.html?lang=de&pays=ch" />
  10. domaine.fr/produit.html?couleur=noir
    <link rel = "canonical" href = "http://domain.com/product.html" />
  11. domaine.fr/produit.html?pays=ch?couleur=noir
    <link rel = "canonical" href = "http://domain.com/product.html?pays=ch" />
  12. domaine.fr/produit.html?lang=de?couleur=noir
    <link rel = "canonical" href = "http://domain.com/product.html?lang=de" />
  13. domaine.fr/produit.html?lang=de&pays=ch&couleur=noir
    <link rel = "canonical" href = "http://domain.com/product.html?lang=de&pays=ch" />

Как видно на графике ниже, канонический rel частично решает проблему. DUST исчез, и дубликат больше не является проблемой для URL-адресов, соответствующих склонениям цветов (покажите мне, если я ошибаюсь), но мы всегда остаемся в «почти дублированном» контексте, где страницы имеют очень сильный контент. близко, ни один не был действительно уникальным в глазах двигателей.

URL-адреса в DUST также могут быть перенаправлены навсегда (301). Это перенаправление будет объявлено в заголовке HTTP или через директиву сервера (Apache) в зависимости от случая.

Это перенаправление будет объявлено в заголовке HTTP или через директиву сервера (Apache) в зависимости от случая

Этап II: внедрение rel alternate и hreflang для обозначения языковых и страновых вариаций

Идея не в том, чтобы полностью раскрыть вам достоинства rel alternate и hreflang, так как Google делает это очень хорошо в его руководящих принципах. Просто чтобы показать вам его интеграцию по определенному сценарию, в сожительстве с другими атрибутами.

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

2 больших преимущества для поисковых систем:

  1. Больше проблем с дублированным контентом
  2. Лучшее распределение и позиционирование в поисковой выдаче по странам

Конкретно, для каждой страницы мы указываем все альтернативные URL-адреса, включая себя . Пример с URL-адресами, возникающими из product.html:

  1. domaine.fr/produit.html
    <link rel = "alternate" href = "http://domain.com/product.html" hreflang = "en-us" />
    <link rel = "alternate" href = "http://domain.com/product.html?pays=ch" hreflang = "en-ch" />
    <link rel = "alternate" hrefang = "http://domain.com/product.html?lang=de&pays=ch" hreflang = "de-ch" />
    <link rel = "alternate" href = "http://domain.com/product.html?lang=de" hreflang = "de-de" />
    <link rel = "canonical" href = "http://domain.com/product.html" />
  2. domaine.fr/produit.html?pays=ch
    <link rel = "alternate" href = "http://domain.com/product.html" hreflang = "en-us" />
    <link rel = "alternate" href = "http://domain.com/product.html?pays=ch" hreflang = "en-ch" />
    <link rel = "alternate" hrefang = "http://domain.com/product.html?lang=de&pays=ch" hreflang = "de-ch" />
    <link rel = "alternate" href = "http://domain.com/product.html?lang=de" hreflang = "de-de" />
    <link rel = "canonical" href = "http://domain.com/product.html?pays=ch" />
  3. domaine.fr/produit.html?lang=de
    <link rel = "alternate" href = "http://domain.com/product.html" hreflang = "en-us" />
    <link rel = "alternate" href = "http://domain.com/product.html?pays=ch" hreflang = "en-ch" />
    <link rel = "alternate" hrefang = "http://domain.com/product.html?lang=de&pays=ch" hreflang = "de-ch" />
    <link rel = "alternate" href = "http://domain.com/product.html?lang=de" hreflang = "de-de" />
    <link rel = "canonical" href = "http://domain.com/product.html?lang=de" />
  4. domaine.fr/produit.html?lang=de&pays=ch
    <link rel = "alternate" href = "http://domain.com/product.html" hreflang = "en-us" />
    <link rel = "alternate" href = "http://domain.com/product.html?pays=ch" hreflang = "en-ch" />
    <link rel = "alternate" hrefang = "http://domain.com/product.html?lang=de&pays=ch" hreflang = "de-ch" />
    <link rel = "alternate" href = "http://domain.com/product.html?lang=de" hreflang = "de-de" />
    <link rel = "canonical" href = "http://domain.com/product.html?lang=de&pays=ch" />
  5. domaine.fr/produit.html?couleur=noir
    <link rel = "canonical" href = "http://domain.com/product.html" />
  6. domaine.fr/produit.html?pays=ch?couleur=noir
    <link rel = "canonical" href = "http://domain.com/product.html?pays=ch" />
  7. domaine.fr/produit.html?lang=de?couleur=noir
    <link rel = "canonical" href = "http://domain.com/product.html?lang=de" />
  8. domaine.fr/produit.html?lang=de&pays=ch&couleur=noir
    <link rel = "canonical" href = "http://domain.com/product.html?lang=de&pays=ch" />

Это нормально? Обратите внимание, что я не рассматривал URL-адреса с цветовыми вариациями с rel alternate. Необязательно видеть бесполезным, поскольку они не предназначены ни для позиционирования себя в движках, ни для индексации, канонический атрибут возвращается к каноническому URL без параметра цвета. Нет смысла интегрировать метатег noindex.

Особый случай: в

зависимости от случая издатель может не захотеть назначать определенную страну своей домашней странице, чтобы охватить как можно больше стран. Тогда значение атрибута hreflang должно быть х-умолчанию ».

Оттуда, вы верите, что дубликат определенно уничтожен? И нет, все еще нет зеленых флагов! Мобильная версия все еще там, чтобы дублировать сайт!

Мобильная версия все еще там, чтобы дублировать сайт

Фаза III: альтернативная версия предназначена не только для языков или регионов!

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

Например, для URL domain.fr/produit.html?pays=ch необходимо найти в части <head> страницы набор следующих аннотаций:
<link rel = "alternate" href = "http://m.domain.com/product.html?pays=ch" media = "только экран и (max-width: 640px)" />
<link rel = "alternate" href = "http://domain.com/product.html" hreflang = "en-us" />
<link rel = "alternate" href = "http://domain.com/product.html?pays=ch" hreflang = "en-ch" />
<link rel = "alternate" hrefang = "http://domain.com/product.html?lang=de&pays=ch" hreflang = "de-ch" />
<link rel = "alternate" href = "http://domain.com/product.html?lang=de" hreflang = "de-de" />
<link rel = "canonical" href = "http://domain.com/product.html?pays=ch" />

И это еще не конец! Сторона мобильного URL, то есть http://m.domaine.fr/produit.html?pays=ch, необходимо интегрировать каноническую ссылку, относящуюся к рабочему столу URL. Обязательно:
<link rel = "canonical" href = "http://domain.com/product.html?pays=ch" />

Бинго! Зеленые флаги вернулись ;-)

Зеленые флаги вернулись ;-)

Исходя из этого, мы можем считать, что технически сайт оптимизирован для многоязычного и «DC free».

Никогда систематически не перенаправляйте весь трафик на определенный язык или страну! Сканирование индексирующих роботов может быть искажено и наказывать SEO. Правильное использование заключается в том, что выбор языка в первую очередь зависит от того, что предлагает поисковая система во время запроса, а затем - от пользователя, которого он выбрал по своему выбору (хранится в cookie).

Полезность sitemap.xml

В сфере SEO я случайно услышал, что файл sitemap.xml мало интересен, поскольку сайт легко индексируется. Да, но нет! Если есть часть true, роль sitemap.xml не ограничивается обнаружением URL индексирующими роботами! В контексте многоязычного сайта вполне возможно передать альтернативные альтернативные аннотации непосредственно в файл sitemap.xml. Это может быть очень полезно, когда техническая интеграция последнего сложна (и, к сожалению, это часто случается).

Вот пример файла sitemap.xml, который использует атрибуты rel alternate и hreflang:

<? xml version = "1.0" encoding = "UTF-8"?> <urlset xmlns = "http://www.sitemaps.org/schemas/sitemap/0.9" xmlns: xhtml = "http: //www.w3 .org / 1999 / xhtml "> <url> <loc> http://domain.com/product.html </ loc> <xhtml: link rel =" alternate "hreflang =" en-us "href =" http: //domain.com/product.html "/> <xhtml: link rel =" alternate "hreflang =" de-de "href =" http://domain.com/product.html?lang=de "/> < xhtml: link rel = "alternate" hreflang = "de-ch" href = "http://domain.com/product.html?lang=de&pays=ch" <xhtml: link rel = "alternate" hreflang = " fr-ch "href =" http://domain.fr/produit.html?pays=ch "/> </ url> (...) </ urlset>

На доске остается тень: игра перенаправлений между десктопом и мобильным сайтом.

Бонус: стратегии перенаправления путем обнаружения «агента пользователя» (с рабочего стола на мобильный сайт)

Нет способа сделать это старым и утомительным, перенаправив весь мобильный трафик в корень мобильного сайта (m.domain.fr). Пользователь должен быть прозрачно перенаправлен на страницу, соответствующую его поиску (наиболее подходящую, если необходимо), при этом автоматически обнаруживая свое устройство (Kindle, планшет, фаблет, смартфон и т. Д.).

Перенаправляет через .htaccess против HTTP-заголовка

Первый важный момент в этом сценарии - не создавать таблицу перенаправлений в .htaccess по очевидным причинам обслуживания и нагрузки на сервер . Действительно, файл .htaccess интерпретируется веб-сервером при каждом отображении страницы, и чем больше правил перенаправления, тем больше увеличивается нагрузка на сервер. Поэтому перенаправление должно происходить в заголовке HTTP вызываемой страницы, например, через функцию PHP, если сайт использует этот язык. Кроме того, мы всегда предпочитаем перенаправления «на стороне сервера» перенаправлениям «клиентского сайта» в JavaScript.

Поэтому для настройки перенаправления необходимо будет вернуть мобильных пользователей по URL-адресу, указанному в атрибуте rel alternate исходной страницы.

Соответствующий синтаксис и в соответствии с рекомендациями Google

Google недавно уточнил свои рекомендации для разработчиков о мобильные перенаправления , Что касается нашего сценария, Google рекомендует перенаправление 302 :

«Правильно перенаправьте содержимое, оптимизированное для смартфона, на новый специфичный для смартфона URL-адрес, используя перенаправления HTTP на стороне сервера 302 (мы рекомендуем не использовать перенаправления JavaScript), и настройте заголовок HTTP». -Агент »для облегчения обнаружения пользователя-агента. "

Что дает этот тип синтаксиса PHP:

<? php header («Статус: 302 временно перемещен», FALSE, 302); заголовок («Vary: User-Agent»); заголовок ("Местоположение: http://mobile.monsite.com/". $ _SERVER ['REQUEST_URI']); Выход (); ?>

Обнаружение агента пользователя (в PHP) с помощью класса Mobile_Detect

Это класс PHP, который значительно облегчает обнаружение мобильных устройств. Гораздо удобнее, чем вести сложный список пользовательских агентов, терминалов, ОС и т. Д. с ошибками, которые он может вызвать. Этот класс можно просмотреть и загрузить с Github ,

Пример интеграции и использования:

включите «Mobile_Detect.php»; $ detect = new Mobile_Detect (); if ($ detect-> isMobile ()) {// Действие для мобильного телефона} if ($ detect-> isTablet ()) {// Действие для планшета} if ($ detect-> isiOS ()) {// Действие для устройства iOS} if ($ detect-> isAndroidOS ()) {// Действие для устройства Android}

В заключение и идти еще дальше ...

Моя статья только царапает поверхность международного SEO, и сложность часто больше и порочнее на «земле»
Моя статья только царапает поверхность международного SEO, и сложность часто больше и порочнее на «земле». Я коснулся только технического аспекта с акцентом на URL-адреса в конкретном контексте. Международное SEO и Multisupport также должны использовать маркетинг, исследования ключевых слов, а также тактические и стратегические планы действий. Часто издатели и marketeux, которые запускают цветочную пушку на международной арене, не осознают необходимых предпосылок, порой приводящих к настоящим кораблекрушениям SEO / SEM.

Иногда мы говорим, что признаем хорошего SEO по его способности полностью освоить международный компонент. Я полностью придерживаюсь. Вот почему мне нравится копать предмет такого типа, и, как это ни парадоксально, чем больше я копаю, тем больше понимаю, что мне еще многое предстоит выучить (особенно в плане маркетинга).

Хорошо, каков план действий?
Ты все еще следишь за мной?
Это становится извращенным, а?
Хорошо, каков план действий?
Html?
Html?
Html?
Html?
Html?
Html?
Stylish-Portal.infO 2011
При копирование материала активная ссылка на сайт!
Copyright 2004-2016 © www.zone55.ru. All rights reserved.