Последствия SEO много языкового сайта с обнаружением системной культуры
Я разработал многоязычный сайт в ASP.NET, который обнаруживает системную культуру пользователя и отображает содержание на соответствующем языке.
Это все работает приятно, но у моего клиента с тех пор был аудит SEO. Агентство по SEO выразило озабоченность, что это не хорошая практика SEO, поскольку нет уникальных URL для каждого языка.
Они предположили, что сайт может быть обвинен в сокрытии, и что Google не может индексировать сайт правильно для каждого различного языка.
Какие-либо идеи о том, являются ли они обоснованной озабоченностью, и если существует преимущество для наличия уникальных URL для каждой языковой версии сайта?
2 ответа
Можно попробовать:
SELECT 'articles' as table_name, id
FROM `articles`
WHERE content like '%<my_string>%'
UNION
SELECT 'news' as table_name, id
FROM `news`
WHERE news like '%<my_string>%'
<UserControl.DataContext>
<vm:ThisUCViewModel />
</UserControl.DataContext>
Хотя вы сделали красивую работу переключение Язык автоматически, SEO агентство правильно!
Этот Google может неправильно индексировать сайт для каждого языка.
Это правда! Google не отправляет заголовок accept-language последний раз, когда я проверял. Это означает, что Google будет индексировать только язык по умолчанию.
Они предположили, что сайт может быть обвинен в маскировке,
Это отличается от вашей реализации Excact, но возможно ваш сайт получит штраф!
Есть преимущество иметь уникальные URL-адреса (для каждой языковой версии) на сайте!
Прежде всего, для ваших пользователей: они могут ссылаться на предпочитаемый ими язык. Вторичный для поисковых систем, поскольку они могут правильно индексировать ваш сайт.
Я советую большую часть времени перенаправлять пользователя только на главную страницу для языкового коммутатора с помощью 302 перенаправлять на правильный URL (и, следовательно, на правильный язык). (изменить: Вы можете просмотреть сообщение Мэтт Каттс «SEO Совет: Обсуждение 302 перенаправления» )
Чтобы проверить мой совет: установить fiddler и перейти к http://www.ibm.com . Как показано ниже, я получил 302 перенаправления на соответствующий язык, прибыв на www.ibm.com/be/en.
Result Protocol Host URL Body Caching Content-Type
4 302 HTTP www.ibm.com / 209 text/html
5 200 HTTP www.ibm.com /be/en/ 5.073 no-cache text/html;charset=UTF-8
Есть несколько решений, которые вы можете решить:
- Начать перезапись Urls (добавление, например, каталога с использованием языка)
- Если вы не хотите пройти через трудности добавления каталогов (или rewriting url's) добавление QuureString было бы самым простым решением (хотя попробуйте ограничить их максимум 2 параметрами)
- Другой вариант - использование другого подзаголовка www.website.com для языка по умолчанию, es.website.com, fr.website.com
Просто убедитесь, что каждый раз вы предоставляете одно и то же содержимое для одного и того же URL-адреса.
Удачи с этим!
Этот совет применим только к однородным иерархиям, то есть иерархиям, в которых производные классы не вводят новых функций (за исключением конструкторов) и просто переопределяют функции базового класса. В этом случае вам, очевидно, не нужно работать с экземпляром line напрямую - только через указатель/ссылку на shape .
Когда у вас менее однородная иерархия, этот совет не имеет большого смысла: как бы кто-либо применил его к случаям, когда производный класс вводит новые функции или наследует их от другого базового класса? В этом случае иногда требуется непосредственно работать с объектами производного класса, и этот совет может привести только к неудобствам.
Дальнейшее развитие этой идеи - менее радикальной и пригодной для использования в большем количестве контекстов - Невиртуальный интерфейс (NVI) Херба Саттера.
-121--4196054- В классе LineItem объявляются неоднозначные связи.
В двух словах, принадлежит _ делает это в вашем классе:
принадлежит _:счет-фактурасоздает методсчета-фактуры, который выполняет поиск в таблице счетов-фактур записи, на которую ссылаетсяinvoice _ idпринадлежит _:записываемый,: polymorphic = > trueсоздает методзаписываемый, который выполняет поиск в таблицеrecordable _ type.underscore.pluralizeдля записи, на которую ссылаетсяrecordable _ idпринадлежит _:credit,:class_name = > "Кредит": foreign _ key = > "recordable_id"создает методкредит, который выполняет поиск в таблице кредит записи, на которую ссылаетсязаписываемый _ id. Обратите внимание, чтозаписываемый тип _здесь игнорируется.- то же самое относится к
_ относится к: дебетусоответственно.
Поскольку ваш LineItem может принадлежать только кредиту или дебету, нет смысла объявлять эти связи дополнительно. К ним можно обратиться через ассоциацию с возможностью записи .
Надеемся, что мы увидим некоторых людей, которые знают о внутренних устройствах Google (кто угодно?). Но большинство предположений о том, как Google и другие краулеры... предположения, и могут измениться.
Я думаю, что вы должны использовать отдельные URL для языков, даже если они просто имеют ? язык = (хотя лучше бы действительно другой URL). Я верю в это, потому что когда вы идете на google.it это говорит, google.com на английском и эта ссылка переходит к... google.com. Другими словами, Google сама использует разные URL-адреса для разных языков.
Кроме того, другой крупный сайт, Microsoft (они, вероятно, знают о SEO) использует
http://www.microsoft.com/en/us/default.aspx
для американо-английского языка и
http://www.microsoft.com/it/it/default.aspx
для Italy-Итальянский, поэтому, вероятно, лучше всего проводить различие на основе языка (и страны).
В любом случае, я совершенно раздражен, когда нахожусь на англоязычном компьютере и не вижу сайт на итальянском или испанском, и наоборот. Как удобство использования, а не стратегия SEO, пользователь должен иметь возможность переопределить предложение языка. Так и большинство крупных сайтов обращаются с языками.