Когда показывать разный контент поисковым движкам и посетителям

⇐ ПредыдущаяСтр 34 из 85Следующая ⇒

Есть несколько причин для показа контента разным посетителям по-разному (и в том числе поисковым движкам). Вот некоторые самые часто встречающиеся.

• Тестирование.

Тестирование целевых страниц для конвертации требует, чтобы вы показывали разным посетителям разный контент (для проверки его работы). В этих случаях лучше всего показывать контент при помощи JavaScript/куки-файлов/сеансов и выдавать поисковым движкам единую (каноническую) версию страницы, которая не меняется при каждом новом просмотре паука (хотя это не обязательно навредит вам). Google предлагает для выполнения этой функции программное обеспечение под названием Google Website Optimizer.

• Требующий регистрации контент и First Click Free.

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

При таком сценарии вы можете также принять участие в специальной программе Google под названием First Click Free, когда web-сайты могут выкладывать ограниченный регистрацией контент для пауков Google, а пользователям (которые щелкают по результатам поискового движка) дается возможность увидеть первую статью бесплатно. Эту тактику используют многие известные web-издатели, в том числе и такой популярный сайт, как Experts-Exchange.com.

Точнее говоря, для реализации First Click Free издатель должен гарантировать роботу Google (и, вероятно, паукам остальных поисковых движков также) доступ ко всему контенту, который он хочет проиндексировать (даже если пользователям нужно зарегистрироваться, чтобы увидеть этот контент). Приходящему на сайт пользователю по-прежнему нужно будет регистрироваться, но пауку поискового движка делать этого не придется. Это приведет к тому, что контент будет показан в результатах поискового движка. Однако если пользователь щелкнет по этому результату поиска, то вы должны будете разрешить ему просмотреть всю статью целиком (все ее страницы, если их не одна). Если пользователь щелкнет по другой статье вашего сайта, вы можете потребовать от него войти в систему.

Подробнее читайте на странице программы First Click Free по адресу http: //googlewebmastercentral.blogspot.com/2008/10/first-click-free-for-web-search.html.

• Навигация, по которой не могут перемещаться поисковые движки.

Если ваша навигация сделана на основе Flash, JavaScript, Java-приложения или имеет другой неизвестный паукам формат, то вам следует предусмотреть показ поисковым движкам версии в виде HTML-контента (по которой движки перемещаться умеют). Многие сайты делают это при помощи слоев CSS, демонстрируя видимый для человека (но невидимый для поиска) слой, а также слой для движков (и менее способных браузеров, таких как мобильные браузеры). Вы можете также использовать для этой цели и тег noscript, хотя это более рискованно, поскольку многие спамеры применяют noscript для сокрытия контента. Компания Adobe недавно запустила портал по оптимизации и технологии Flash и описывает там лучшие практики, которые одобрены поисковыми движками (чтобы помочь обнаружению Flash-контента). Убедитесь в том, что показанный в видимом для поиска слое контент в основном совпадает с тем, который находится в видимом для человека слое.

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

Если существенная часть контента страницы дублированная, то необходимо обдумать возможность ограничить доступ к ней пауков поисковых движков (разместив ее внутри i-фрейма, ограниченного файлом robots.txt). Это гарантирует то, что вы сможете показывать движкам уникальную часть вашей страницы и защищаться от проблем дублированного контента. Мы обсудим это более подробно в следующем разделе.

• Разный контент для разных пользователей.

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

Как показывать поисковым движкам и посетителям разный контент

Для сегментирования поставки контента имеются самые разные стратегии. Самая простая – предоставлять непредназначенный для поисковых движков контент в недоступном для пауков формате (т. е. размещать текст в изображениях, Flash-файлах, дополнительных модулях и т. д.). Для клоакинга эти форматы использовать не следует. Их нужно применять только в том случае, когда они дают существенную пользу для конечных пользователей (например, улучшают их впечатление). В таких случаях вы, вероятно, захотите показать поисковым движкам тот же самый контент в доступном для пауков формате. Когда вы стараетесь показывать поисковым движкам то, что не хотите показывать посетителям, то можете использовать стили форматирования CSS (но желательно не display: none, поскольку у движков могут иметься фильтры для наблюдения именно за этим), скрипты JavaScript, агента пользователя, куки-файлы или сеансы, а эффективнее всего поставку по IP-адресу (показ контента в зависимости от IP-адреса посетителя).

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

Файл robots.txt

Этот файл находится в корневом уровне вашего домена (например, http: //www.yourdomain.com/robots.txt) и является чрезвычайно универсальным инструментом для управления тем, к чему разрешается доступ паукам поисковых движков на вашем сайте. Вы можете использовать файл robots.txt для того, чтобы:

• предотвратить доступ пауков к непубличным разделам вашего сайта;

• заблокировать доступ поисковым движкам к скриптам индексирования, утилитам и прочему коду;

• избежать индексирования дублированного контента web-сайта (такого, как версии для печати HTML-страниц или различные сортировки каталогов товаров);

• автоматически обнаружить XML Sitemap.

Файл robots.txt должен находиться в корневом каталоге, название файла должно быть полностью набрано в нижнем регистре (robots.txt, а не Robots.txt или какой-либо другой вариант с использованием букв верхнего регистра). Любое другое название или местоположение поисковыми движками не признается. Файл должен быть в текстовом формате (а не в формате HTML).

Когда вы говорите роботу поисковых движков, что обращаться к данной странице не нужно, он предотвращает доступ паука к странице. На рис. 6.31 показано, что происходит, когда робот поискового движка видит указание в файле robots.txt не просматривать web-страницу.

Рис. 6.31. Влияние файла robots.txt

По существу страница просматриваться не будет, так что ссылки этой страницы не могут передавать свой " сок" другим страницам (поскольку поисковый движок ссылок не видит). Однако страница может находиться в индексе поискового движка. Такое может произойти, если на данную страницу делают ссылки другие страницы Интернета. Конечно, поисковый движок не получит много информации с такой страницы (поскольку он не может ее прочитать) и будет полагаться в основном на якорный текст и прочие сигналы ссылающихся на нее страниц (чтобы определить, о чем может быть данная страница). В результате соответствующие результаты поиска в Google выглядят очень разреженными (рис. 6.32).

Рис. 6.32. SERP для страниц, которые занесены в файл robots.txt

На рисунке показаны результаты для запроса site: news.yahoo.com/topics/ inurl: page в поисковике Google. Это не обычный запрос, который мог бы ввести пользователь, но вы можете видеть, как выглядят результаты. Выдан только список URL, а описаний нет. Это происходит потому, что паукам не разрешается читать страницу, чтобы получить эти данные. При сегодняшних алгоритмах такие страницы не имеют высокого рейтинга, т. к. их релевантность чрезвычайно низка (для любых нормальных запросов).

Google, Yahoo! Bing, Ask и почти все легальные пауки Интернета выполняют сделанные вами в файле robots.txt указания. Команды файла robots.txt в основном используются для предотвращения доступа пауков к страницам и подкаталогам сайта, хотя у них есть и другие опции. Обратите внимание, что для поддомена требуется свой собственный файл robots.txt (точно так же, как и для файлов, находящихся на сервере https: ).

Синтаксис файла robots.txt

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

• Disallow: для тех страниц, доступ к которым вы хотите закрыть от роботов (столько строк Disallow, сколько вам нужно);

• Noindex: для тех страниц, доступ к которым вы хотите закрыть от поискового движка и не индексировать (или удалить из индекса, если они были ранее проиндексированы). Эта функция неофициально поддерживается Google и не поддерживается движками Yahoo! и Bing.

Есть некоторые ограничения:

• каждая группа (агент пользователя/Disallow) должна отделяться пустой строкой, однако внутри группы пустых строк существовать не должно (от строки агента пользователя и до последнего Disallow);

• символ # может использоваться в файле robots.txt для комментариев (все, что находится в строке после символа #, игнорируется). Комментарий можно использовать как на всю строку, так и на остаток строки;

• каталоги и имена файлов чувствительны к регистру: private, Private и PRIVATE – эти имена для поисковых движков уникальны.

Вот пример файла robots.txt:

User-agent: Googlebot

Disallow:

User-agent: msnbot

Disallow: /

# заблокировать всем роботам доступ к каталогам tmp и logs

User-agent: *

Disallow: /tmp/

Disallow: /logs # для каталогов и файлов с названием logs

В этом примере делается следующее:

• роботу Googlebot разрешается заходить куда угодно;

• роботу msnbot запрещается просмотр всего сайта;

• всем роботам (кроме Googlebot) блокируется посещение каталога /tmp/ или каталогов (либо файлов) с названием /logs (т. е. /logs или logs.php).

Обратите внимание, что на поведение Googlebot не влияют такие инструкции, как Disallow: /. Поскольку в файле robots.txt для Googlebot есть персональные инструкции, то он будет игнорировать директивы, помеченные как предназначенные для всех роботов (с использованием звездочки).

Неопытные web-мастера часто встречаются с проблемой, которая возникает тогда, когда у них инсталлирован SSL (чтобы страницы можно было выдавать через HTTP и HTTPS). Файл robots.txt по адресу http: //www.yourdomain.com/robots.txt не будет восприниматься поисковыми движками как указание насчет просмотраhttps: //www.yourdomain.com. Для этого вам нужно будет создать дополнительный файл robots.txt по адресу https: //www.yourdomain.com/robots.txt.

Итак, если вы хотите разрешить просмотр всех страниц вашего сервера HTTP и запретить просмотр всех страниц сервера HTTPS, то вам нужно реализовать следующее:

Для HTTP:

User-agent: *

Disallow:

Для HTTPS:

User-agent: *

Disallow: /

Это самые основы применения файлов robots.txt, однако существуют и более сложные методы. Некоторые из этих методов поддерживаются не всеми движками, как это показано в следующем списке:

• Crawl delay (Задержка перед просмотром).

Эта директива поддерживается Yahoo! Bing и Ask. Она дает указание пауку ждать указанное количество секунд до того, как начать просмотр страниц. Цель этой директивы – снизить нагрузку на сервер издателя:

User-agent: msnbot

Crawl-delay: 5

• Pattern matching (Сопоставление с образцом).

Сопоставление с образцом используется Google, Yahoo! и Bing. Ценность этой директивы велика. Вы можете делать сопоставление с образцом (при помощи группового символа " звездочка" ). Вот пример использования сопоставления с образцом для блокирования доступа ко всем подкаталогам, которые начинаются с private (например: /private1/, /private2/, /private3/ и т. д.):

User-agent: Googlebot

Disallow: /private*/

Вы можете обозначить конец строки при помощи знака доллара. Например, для блокирования таких URL, которые заканчиваются на. asp:

User-agent: Googlebot

Disallow: /*.asp$

Вы можете пожелать предотвратить доступ роботов к любым URL, которые содержат параметры. Для блокирования доступа ко всем URL, которые содержат знак вопроса, просто используйте знак вопроса:

User-agent: *

Disallow: /*? *

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

• Директива Allow.

Директива Allow поддерживается только в Google, Yahoo! и Ask. Она работает как противоположность директивы Disallow и дает возможность конкретно указывать те каталоги или страницы, которые можно просматривать. Когда эта возможность реализуется, она может частично перекрыть предыдущую директиву Disallow. Это может пригодиться в том случае, когда были запрещены большие разделы сайта (либо когда запрещен весь сайт целиком).

Вот пример, в котором роботу Googlebot разрешается доступ только в каталог google:

User-agent: Googlebot

Disallow: /

Allow: /google/

• Директива Noindex.

Эта директива работает точно так же, как и команда meta robots noindex (которую мы скоро обсудим). Она говорит поисковым движкам, что надо однозначно исключить страницу из индекса. Поскольку Disallow предотвращает просмотр, но не индексирование, то Noindex может быть очень полезной функцией для того, чтобы гарантировать отсутствие страниц в результатах поиска. Однако по состоянию на октябрь 2009 г. эту директиву в файле robots.txt поддерживает только Google.

• Sitemap.

Мы обсуждали XML Sitemap в начале этой главы. Вы можете использовать robots.txt для предоставления пауку механизма автоматического обнаружения местонахождения файла XML Sitemap. Поисковому движку можно сказать о местонахождении этого файла одной простой строкой в файле robots.txt:

Sitemap: sitemap_location

sitemap_location – это полный URL к Sitemap (такой, как http: //www.yourdomain.com/sitemap.xml). Вы можете разместить эту строку в любом месте вашего файла.

Полные указания по применению файла robots.txt смотрите на сайте Robots.txt.org (http: //www.robotstxt.org/orig.html). Для экономии времени и сил вы можете также воспользоваться инструментом генерирования файла robots.txt, который разработал Dave Naylor (http: //www.davidnaylor.co.uk/the-robotstxt-builder-a-new-tool.html).

Будьте очень осторожны при внесении изменений в файл robots.txt. Например, простая опечатка может внезапно сказать поисковым движкам, что они больше не должны вообще просматривать ваш сайт. После обновления файла robots.txt всегда полезно проверить его при помощи инструмента Test Robots.txt (http: //www.google.com/webmasters/tools/crawl-access) из набора инструментов Google Webmaster Tools.

Атрибут Rel=" NoFollow”

В 2005 г. три основных поисковых движка (Yahoo! Google, и Microsoft) достигли согласия насчет поддержки инициативы, направленной на снижение эффективности автоматического спама. В отличие от версии meta robots директивы NoFollow, новую директиву можно было использовать как атрибут внутри тега < a> или тега ссылки (чтобы указать, что ссылающийся сайт не ручается за качество той страницы, на которую сделана ссылка). Это позволяет создателю контента делать ссылку на web-страницу без передачи ей всех тех нормальных преимуществ поисковых движков, которые следуют из ссылки (доверие, якорный текст, рейтинг PageRank и т. д.).

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

Вы можете реализовать NoFollow с помощью следующего формата:

< a href=" http: //www.google.com" rel=" NoFollow" >

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

На рис. 6.33 показано, как робот поискового движка интерпретирует атрибут NoFollow, когда он находит его связанным со ссылкой (в данном примере это Link 1).

Рис. 6.33. Воздействие атрибута NoFollow

Ссылка с атрибутом NoFollow не передает " сок ссылок". Никакие другие аспекты работы поисковых движков со страницей не изменяются.

После введения атрибута NoFollow стала популярной идея накачки с его помощью рейтинга PageRank. Существовало такое мнение, что когда вы делаете NoFollow по конкретной ссылке, то " сок ссылок" (который должен передаваться этой ссылке) сохраняется, а поисковые движки перераспределяют его другим найденным на этой странице ссылкам. В результате многие издатели реализовали ссылки NoFollow на менее ценные страницы своих сайтов (такие, как " Информация о нас" и " Свяжитесь с нами" или страницы товарных каталогов с альтернативными сортировками). Фактически опубликованные в марте 2009 г. данные из инструмента SEOmoz Linkscape (http: //www.seomoz.org/linkscape) показали, что на тот момент примерно 3 % всех ссылок в Интернете были с NoFollow и что 60 % этих NoFollow были применены к внутренним ссылкам.

Однако в июне 2009 г. Matt Cutts (из компании Google) написал пост, после которого стало ясно, что связанный со ссылкой NoFollow " сок" отбрасывается, а не перераспределяется (http: //www.mattcutts.com/blog/pagerank-sculpting/). Теоретически вы при желании можете использовать NoFollow, но применение его для внутренних ссылок не даст (по состоянию на сегодняшний день и в соответствии с утверждениями Google) тех преимуществ, на которые мы ранее рассчитывали. В действительности (при некоторых сценариях) это может быть даже вредно.

А вот пример, иллюстрирующий эту проблему. Если издатель использует 500-страничный сайт и на каждой странице имеется ссылка на страницу " Информация о нас" и все эти ссылки помечены как NoFollow, то это отрежет " сок ссылок", который иначе посылался бы на страницу " Информация о нас". Однако поскольку этот " сок ссылок" отбрасывается, то остальная часть сайта никакой пользы не получает. Если же атрибуты NoFollow удалить, то страница " Информация о нас" будет передавать хотя бы часть " сока ссылок" обратно на остальную часть сайта (через ссылки на странице " Информация о нас" ).

Это хорошая иллюстрация постоянно меняющейся сути оптимизации. То, что раньше было популярной и эффективной тактикой, в настоящий момент рассматривается как неэффективное средство. Некоторые агрессивные издатели будут продолжать накапливать " сок ссылок" при помощи еще более агрессивных методов, таких как реализация ссылок внутри JavaScript или внутри i-фреймов (для которых стоит Disallow в файле robots.txt), так что поисковые движки не будут видеть этих ссылок. Такая агрессивная тактика, вероятно, не стоит затраченных на нее усилий (для большинства издателей).

Метатег robots

Метатег robots имеет три компонента: cache, index и follow. Компонент cache дает указание поисковому движку о том, может ли он хранить в публичном индексе движка страницу, доступ к которой осуществляется через ссылку cached snapshot в результатах поиска (рис. 6.34).

Рис. 6.34. Моментальный снимок экрана с кэшированным элементом в страницах SERP

Второй компонент index говорит движку о том, разрешается ли просматривать эту страницу и сохранять ее в каком-либо виде. Помеченная как NoIndex страница будет полностью исключена поисковыми движками. По умолчанию это значение равно index, что говорит поисковым движкам: " Да, просматривайте, пожалуйста, эту страницу и включите ее в ваш индекс". Таким образом, размещать эту директиву на каждой странице не нужно. На рис. 6.35 показано то, что делает робот поискового движка при обнаружении тега NoIndex на web-странице.

Рис. 6.35. Воздействие тега NoIndex

Робот по странице все равно будет ползать, и страница может по-прежнему аккумулировать и передавать " сок ссылок" другим страницам, но она не появится в индексах поисковых движков.

Последняя инструкция, которая имеется в метатеге robots, – это follow. Эта команда (подобно index) имеет по умолчанию значение yes (" ползать по ссылкам на данной странице и передавать “сок ссылок” между ними" ). Применение NoFollow говорит поисковому движку о том, что ссылки на данной странице не должны передавать стоимость ссылок или подвергаться просмотру. В общем и целом неразумно использовать эту директиву как способ предотвращения перемещения по ссылкам. Поскольку люди все равно смогут попадать на эти страницы и смогут сделать ссылки на них с других сайтов, то NoFollow (в метатеге robots) мало что дает в смысле ограничения просмотра или доступа пауков. Единственное его назначение – предотвращение распыления " сока ссылок", что имеет весьма ограниченное применение, поскольку в 2005 г. был введен атрибут rel=" nofollow" (который мы уже обсуждали), позволяющий размещать эту директиву в отдельных ссылках.

На рис. 6.36 дана схема поведения робота поискового движка при обнаружении метатега NoFollow на web-странице.

Рис. 6.36. Воздействие метатега NoFollow

Когда вы применяете метатег NoFollow на странице, то поисковый движок все равно просмотрит страницу и поместит ее в свой индекс. Однако все ссылки (и внутренние, и внешние) этой страницы не смогут передавать " сок ссылок" другим страницам.

Хорошим применением для NoIndex является размещение этого тега на HTML-странице с картой сайта. Эта страница создана для навигационной помощи пользователям и паукам поисковых движков, чтобы они могли эффективно обнаруживать контент вашего сайта. И, несмотря на то, что на некоторых сайтах эти страницы вряд ли могут получить хоть какой-то заметный рейтинг в поисковых движках, вы все равно хотите, чтобы они передавали " сок ссылок" тем страницам, на которые они ссылаются. Размещение на этих страницах NoIndex не позволяет включать эти HTML-карты в индексы (и проблема таким образом решается). Убедитесь в том, что вы не применяете метатег NoFollow на этих страницах или атрибут NoFollow в ссылках на эти страницы, поскольку это не позволит страницам передавать " сок ссылок".

Тег canonical

В феврале 2009 г. компании Google, Yahoo! и Microsoft объявили новый тег, известный как тег canonical. Этот тег был новой конструкцией, созданной специально для целей выявления дублированного контента и работы с ним. Реализация его очень проста и выглядит так:

< link rel=" canonical" href=" http: //www.seomoz.org/blog" />

Этот тег должен сказать Yahoo! Bing и Google о том, что данная страница должна считаться копией URL http: //www.seomoz.org/blog и что все показатели (ссылок и контента) поисковых движков должны применяться именно к этому URL (рис. 6.37).

Рис. 6.37. Как поисковые движки рассматривают тег canonical

Тег canonical во многом похож на 301-й редирект (с точки зрения оптимизации). По существу, вы говорите поисковым движкам, что множество страниц нужно рассматривать как одну (именно это делает 301-й редирект) без фактического перенаправления посетителей на новый URL (что часто экономит усилия ваших разработчиков).

Имеются, однако, и некоторые отличия:

• в то время как 301-й редирект направляет весь трафик (как роботов, так и посетителей), тег canonical предназначен только для поисковых движков. А это значит, что вы по-прежнему можете отслеживать посетителей уникальных версий;

• 301-й редирект является гораздо более сильным сигналом о том, что множество страниц имеет один канонический источник. Несмотря на то, что поисковые движки планируют поддерживать этот новый тег и доверяют намерениям владельцев сайтов, будут также и ограничения. Чтобы гарантировать, что владелец сайта применил этот тег не по ошибке и не для жульничества, будут применяться анализ контента и прочие алгоритмические показатели. И вы, конечно, увидите примеры ошибочного применения тега canonical, а это приведет к тому, что движки будут держать в своих индексах эти различные URL (т. е. у владельцев сайтов будут те же самые проблемы, которые были отмечены в разд. " Проблемы дублированного контента" этой главы);

• 301-й редирект имеет междоменную функциональность, а это означает, что вы можете перенаправить страницу из Domain1.com в Domain2.com и перенести все показатели поисковых движков. В случае с тегом canonical это не так, он работает исключительно в одном домене (переносит между подкаталогами и поддоменами).

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

⇐ Предыдущая 29 30 31 32 333435 36 37 38 Следующая ⇒