Новости

7 способов потерпеть неудачу на международном SEO

  1. 1. Не используйте разные URL для каждой из ваших международных веб-версий
  2. 2. Автоматическое перенаправление пользователей на международную веб-версию без предоставления возможности...
  3. Краткий обзор Google
  4. Примеры
  5. 3. Не локализуйте содержимое ваших разных версий веб-страны
  6. 4. Использование единого ccTLD для таргетинга на многие страны
  7. 5. Предполагая, что Google поддерживает континентальный таргетинг с доменами .asia или .eu или значениями...
  8. 6. Канонизация всех ваших международных веб-версий в одну, чтобы избежать проблем с дублированием контента
  9. 7. Внедрение аннотаций Hreflang без выполнения процесса, включающего валидацию

Создание многоязычного и / или мультистранового присутствия в Интернете для расширения охвата вашего бизнеса более широкой международной аудиторией требует глубокого понимания ваших целевых рынков, а также международных знаний в области SEO, чтобы должным образом отразить желаемую ориентацию на ваш сайт. настройка, разработка контента, оптимизация и продвижение.

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

Хотя есть много правила, которые должны знать маркетологи Вот некоторые из наиболее распространенных проблем и способов потерпеть неудачу в International SEO (и как вы можете их избежать):

1. Не используйте разные URL для каждой из ваших международных веб-версий

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

Как Google упоминает в своем собственном официальная документация : « Google не может сканировать, индексировать или оценивать весь ваш контент для разных языков. Это связано с тем, что стандартные IP-адреса сканера Googlebot, по-видимому, базируются в США. Кроме того, сканер отправляет HTTP-запросы без указания Accept-Language в заголовке запроса. »

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

Важно также, чтобы посетители постоянно отображали фактическую версию URL-адреса страницы, относящуюся к языку или стране, когда они попадают на сайт или когда выбирают перейти на эту версию. Эта стратегия лучше, чем то, что делают некоторые сайты, такие как Entrepreneur; в приведенном ниже примере они выбирают показ испанской версии домашней страницы по тому же URL-адресу, что и на английском (https://www.entrepreneur.com/), когда идентифицируют, что пользователь использует браузер на испанском языке.

com/), когда идентифицируют, что пользователь использует браузер на испанском языке

В этом нет необходимости, так как у Entrepreneur фактически есть испанская версия домашней страницы, отображаемая через собственный URL ( https://www.entrepreneur.com/es ), как можно увидеть ниже. В этом случае это будет соответствующий URL-адрес, чтобы избежать путаницы, позволяющей пользователям, говорящим по-испански, ссылаться или делиться им.

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

2. Автоматическое перенаправление пользователей на международную веб-версию без предоставления возможности ее выбора.

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

Краткий обзор Google

На данный момент, большинство IP-адресов Googlebot все еще из США; Google пока не сканирует все страны (сканеры в основном из США и некоторых других стран). Поэтому, если мы перенаправим только на версию сайта для этих стран, робот Google будет всегда перенаправлен и увидит только несколько версий нашего сайта, а не все.

Вы не просто перенаправляете пользователей, но и ботов. Вот почему лучше разрешить не только пользователю просматривать любую международную версию, в которой он появился, но и роботу Google сканировать любую версию, а не перенаправлять ее на основании своего IP-адреса.

Примеры

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

Вместо перенаправления рекомендуется разрешить пользователям доступ к первоначально выбранной международной веб-версии, при этом уведомляя их о том, что для них может существовать более релевантная версия языка или страны на основе их IP-адреса браузера или страны. Вы можете сделать это ненавязчивым и наглядным способом, предоставив им возможность либо сохранить, либо изменить версии, как это делает Autodesk.

3. Не локализуйте содержимое ваших разных версий веб-страны

Даже если вы ориентируетесь на разные страны, говорящие на одном языке, вы можете подумать, что вы можете повторно использовать контент в разных версиях вашего сайта; ты не должен Крайне важно, чтобы контент, который представлен в каждом из них, был локализован, ориентирован на определенное поведение аудитории на рынке каждой страны. Содержание может отличаться, даже если используется один и тот же язык. Вещи, которые могут отличаться, могут быть конкретными терминами, используемыми для описания сезонности, или разными локализованными словами для описания продуктов или услуг. Несмотря на общий язык, предпочтения могут меняться от страны к стране.

Например, мы можем видеть, как в американской версии сайта Adidas есть категория «Футбольные бутсы», которая называется «Футбольные бутсы» в их британской версии, поскольку они были локализованы для подключения и адресации поиска пользователей в каждом из них. страна - которая отличается в этом случае, даже если они говорят на одном языке.

страна - которая отличается в этом случае, даже если они говорят на одном языке

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

4. Использование единого ccTLD для таргетинга на многие страны

Сайты, которые начинают с таргетинга на определенную страну, обычно свою собственную, и используют свой конкретный ccTLD (домены верхнего уровня с кодом страны, такие как .uk, .mx, .es, .fr или .de, которые по умолчанию уже геолокализованы), могут иметь вызов, когда нужно расширяться на международном уровне.

У них не будет возможности использовать этот исходный нДВУ для таргетинга на другие страны, как вы можете сделать с рДВУ (родовыми доменами верхнего уровня, такими как .com, .org, .net), которые не связаны с конкретной страной. Домен рДВУ можно использовать для таргетинга на многие страны, включив подкаталоги или субдомены, которые можно геолокализовать через консоль поиска Google.

К сожалению, некоторые компании не знают об этих вариантах и ​​пытаются нацелить на другие страны, предоставляя подкаталоги для разных регионов, на которые они хотят ориентироваться в рамках ccTLD, который уже привязан к другому. Мы можем видеть это в приведенном ниже примере с версией для США в подкаталоге, расположенном в .co.uk (ccTLD, который по умолчанию уже привязан к Великобритании).

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

5. Предполагая, что Google поддерживает континентальный таргетинг с доменами .asia или .eu или значениями «eu» в Hreflang

Google не поддерживает (по крайней мере пока) региональный таргетинг на уровне континента, используя региональные домены верхнего уровня, такие как .eu или .asia. которые рассматриваются как рДВУ или используя региональные значения, такие как «ЕС» для Европы в hreflang, так как Google поддерживает ISO 3166-1 альфа-2 коды стран для них ,

Важно учитывать это при принятии решения о том, следует ли устанавливать присутствие с доменом .eu при нацеливании на Европу; тогда вместо этого может быть лучше использовать рДВУ с конкретными подкаталогами, которые можно геолокации через консоль поиска Google и помечать аннотациями hreflang, чтобы ориентироваться на конкретные европейские страны на индивидуальном уровне.

eu при нацеливании на Европу;  тогда вместо этого может быть лучше использовать рДВУ с конкретными подкаталогами, которые можно геолокации через консоль поиска Google и помечать аннотациями hreflang, чтобы ориентироваться на конкретные европейские страны на индивидуальном уровне

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

Иногда, даже после прохождения процесса локализации, из-за характера вашего бизнеса, вы можете получить очень похожий контент в разных версиях для стран, говорящих на одном языке (например, английский в США, Великобритании или Австралии).

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

Иногда путаница может возникнуть из-за канонизации по всей стране, которую можно увидеть на некоторых известных сайтах, как, например, в примере с Airbnb ниже, в котором мы можем увидеть, как они канонизируют свою мексиканскую домашнюю страницу с версией испанской домашней страницы в Домен .com. Тем не менее, мы не знаем контекста, в котором было принято решение для этой конфигурации, и с другой стороны, мы можем видеть, что на тех рынках, где у них есть активное деловое и органическое поисковое присутствие, таких как Великобритания, Франция или Испания, они самостоятельно канонизируем это.

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

7. Внедрение аннотаций Hreflang без выполнения процесса, включающего валидацию

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

Как правило, эти ошибки обычно происходят из-за отсутствия процесса реализации hreflang, который включает в себя проверку, которая выглядела бы примерно так:

A. Оценка объема реализации языка и страны

Выявление версий языков и стран, в которых необходимо использовать hreflang, особенно тех, в которых найдены результаты поиска смещения в международном масштабе, которые могут быть приоритетными.

Б. Выбор метода реализации

Оценка наиболее подходящего метода реализации hreflang (теги в заголовке HTML, заголовок HTTP или карта сайта XML) на основе требований сайта и проекта, а также ограничений.

C. Указание шаблона кода Хрефланга

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

D. Проверка реализации Hreflang в тестовой среде

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

E. Мониторинг и устранение неполадок реализации Hreflang после запуска

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

F. Создание руководящих принципов Hreflang Best Practices, которым необходимо следовать

Документирование области применения и правил реализации hreflang, которые необходимо соблюдать для определения передового опыта, на основе которого они могут учитываться при публикации страниц соответствующих языков и / или стран, а также при изменении или удалении их URL-адресов. Эта документация необходима для того, чтобы аннотации hreflang могли обновляться и проверяться соответствующим образом.

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

Надеемся, что этот пост поможет вам избежать этих довольно распространенных международных проблем SEO, и если вы столкнулись с какой-либо из них в данный момент, вы теперь будете знать, как их решить.