SEO-тактики (4 штуки), неофициально поддерживаемые Google 

Автор – Сэм Марсден (Sam Marsden), SEO и контент-менеджер в DeepCrawl

В последнее время Google стал намного лучше взаимодействовать с SEO-сообществом. Будь то объявления о последних обновлениях, публикация документации или ответы на прямые вопросы, – компания обычно чётко проговаривает, что работает и не работает в поиске. Однако есть ряд техник, которые Google официально не поддерживает, но при этом они всё ещё эффективны – в той или иной степени.

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

Что Google неофициально поддерживает?

• Директива noindex в файле robots.txt

Метатеги noindex, используемые на уровне страницы, – это проверенный и надёжный способ закрыть страницы от попадания в поисковые индексы. Однако Google также учитывает большинство директив в файле robots.txt, включая noindex.

Официально сотрудник Google Джон Мюллер заявил, что не стоит полагаться на директиву noindex в файле robots.txt. Однако наше тестирование в DeepCrawl показало, что этот метод закрытия страниц от индексации по-прежнему работает.

В отличие от метатега noindex, директива noindex в файле robots.txt предоставляет более чёткий и управляемый способ сообщить Google о том, что страница не должна индексироваться. Этот метод убирает путаницу в том, какие директивы имеют больший вес, поскольку директивы в _robots.tx_t более важны, чем директивы на уровне URL.

Использование noindex в robots.txt также предпочтительно потому, что в данном случае вы можете блокировать от индексации сразу группы URL, а не закрывать их по одному.

Как и любую другую директиву в robots.txt, вы можете протестировать noindex с помощью Инструмента проверки файла robots.txt.

• Канонические теги, внедряемые с помощью JavaScript

На конференции Google I/O в мае Том Гринуэй (Tom Greenaway) заявил, что Google обрабатывает rel=canonical только при первоначальном извлечении страницы. Если же сайт полагается на рендеринг на стороне клиента, то этот атрибут будет пропущен.

Если это правда, то тогда у SEO-специалистов, которые вносят изменения через Диспетчер тегов Google, возможны проблемы.

Джон Мюллер повторил точку зрения Гринуэя в Twitter.

Собственно, всё понятно, не так ли? Нет, не совсем.

Иоган Хенн (Eoghan Henn) и команда searchViu провели тестирование, которое показало, почему не стоит верить Google на слово.

После добавления rel=canonical через Диспетчер тегов Google, Хенн обнаружил, что поисковик учитывает эти атрибуты и правильно определяет канонические страницы. Полученные результаты явно противоречат рекомендациям Google.

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

Итак, какой вывод можно сделать?

Внедрение канонических тегов в обрабатываемую версию страницы – это не идеальный сценарий, поскольку, как показали тесты Хенна, Google требуется порядка трёх недель, чтобы подхватить указанный URL.

Однако намного более важным здесь является то, что нельзя принимать на веру всё, что говорят представители Google. Мы должны проводить собственные тесты, чтобы проверять или отвергать любые предположения – независимо от того, кем они были высказаны.

• Атрибуты hreflang в анкорных ссылках

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

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

Несмотря на заявление Мюллера, на одном из сайтов нашего клиента мы видели, что атрибуты hreflang в анкорных ссылках на самом деле поддерживаются – как минимум, частично.

Данный сайт не добавлял hreflang больше нигде, кроме анкорных ссылок, и в Search Console мы видели, что десятки тысяч из них были учтены.

Стоит отметить, что не все атрибуты hreflang на сайте нашего клиента отображались в Search Console. Это говорит о том, что Google лишь частично поддерживает этот метод.

Сейчас мы продолжаем проводить тестирование, чтобы понять, почему одни атрибуты подхватываются, а другие – нет.

• Схема сканирования AJAX

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

Данный подход предполагает использование #! для указания параметра, который позволяет поисковым системам переписывать URL-адрес и запрашивать контент со статической страницы.

На большинстве AJAX-сайтов это решение было плохо реализовано, но, к счастью, сегодня такие решения, как HTML5 History API позволяют иметь и динамически загружаемый контент, и нормальные URL. Кроме того, Google также не стоит на месте. В последние годы поисковик значительно улучшил свои возможности в области сканирования AJAX и необходимость применения специальной схемы отпала. Поддержка этого решения должна была быть отключена к концу второго квартала 2018 года.

Сейчас мы уже в третьем квартале, а Джон Мюллер недавно заявил, что поисковик уже практически отказался от схемы сканирования AJAX. То есть, хотя схема сканирования AJAX официально упразднена, но полностью Google от неё пока не отказался.

Что Google не поддерживает

В этой части статьи мы рассмотрим обратную сторону – те вещи, которые Google на самом деле не поддерживает. По крайней мере, пока.

• Директива crawl delay в файле robots.txt

На заре интернета было полезно использовать директиву crawl delay в файле robots.txt, чтобы указать, сколько секунд поисковые роботы должны ждать перед отправкой каждого следующего запроса.

Современные серверы способны справляться с высокими объёмами трафика, поэтому эта директива больше не нужна и Google её игнорирует.

Если же вы хотите изменить скорость сканирования сайта, то это можно сделать на вкладке «Настройки сайта» в Search Console.

Стоит отметить, что не все поисковики отказались от поддержки директивы crawl delay. Так, Bing по-прежнему её учитывает.

• Атрибуты языка

Google полностью игнорирует атрибут lang. Вместо этого он использует собственную систему и определяет язык страницы, анализируя текст.

• Атрибуты change frequency и priority в файлах Sitemap

Атрибуты change frequency (частота обновлений сайта) и priority (приоритет индексации страниц) – ещё один пример инициативы, призванной улучшить сканирование, но не давшей ожидаемого результата из-за плохой реализации вебмастерами.

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

К сожалению, распространённой практикой среди вебмастеров был выбор наивысшего приоритета (1.0), что сделало всю эту систему бесполезной.

Сотрудник Google Гэри Илш недавно подтвердил, что поисковик не обращает внимания на значения priority, заданные в файлах Sitemap, а вместо этого полагается на собственную логику того, как часто должна индексироваться страница.

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

Атрибут change frequency, который был призван сигнализировать поисковым системам, как часто обновляется страница (ежедневно, еженедельно или ежемесячно), также не используется Google для определения скорости сканирования.

• Cookies

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

Google может использовать cookies только в одном случае: если контент не работает без них.

• HTTP/2

Внедрение HTTP/2 может значительно повысить скорость сайта. Однако в глазах Google это не даёт видимых преимуществ, поскольку поисковик использует в сканировании HTTP/1.1. Поэтому, на данный момент, внедрение HTTP/2 выгодно только с точки зрения улучшения пользовательского опыта.

Подведём итоги

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

Основные выводы:

• Не принимайте на веру всё, что говорят сотрудники Google. Я не хочу сказать, что Google намеренно обманывает вебмастеров, однако всегда возможны искажения, учитывая, какое большое количество людей вовлечено в поддержание и развитие поисковых алгоритмов.
• Те техники, которые раньше работали, могут перестать давать результат. SEO – это постоянно развивающееся и меняющееся пространство. И об этом важно помнить.
• Проверяйте то, что вам говорят. Если это невозможно, задавайте вопросы и помогайте распространять результаты полезных исследований, чтобы улучшать коллективное понимание.

Источник: Search Engine Journal и email-рассылка Searchengines.ru