Как Google реагирует на изменения страницы с помощью Диспетчера тегов (GTM)
Автор: Йохан Хенн (Eoghan Henn), сооснователь searchVIU.com
Перевод: Владимир Харев, руководитель поисковой оптимизации медиапроектов Mail.Ru Group, руководитель сервиса SEOSan(мониторинг изменения сайтов для SEO-специалистов)
После нашего небольшого SEO-эксперимента с JavaScript (JS), когда мы добавляли тег hreflang на страницу с помощью Диспетчера тегов (эксперимент прошел упсешно, Google учел его, т.е. использовал post-DOM HTML — прим. пер.), мы решили запустить еще несколько тестов. Их целью было выяснить, как Google учитывает модификацию содержимого страницы через JS, внедренный через Диспетчер тегов.
- Распознает ли Google изменения в теге Title и Meta description, произведенные через Диспетчер тегов?
- Удалит ли Google из индекса страницы с тегом Noindex?
- Учтет ли тег Canonical?
- Проиндексирует ли страницу, внутренняя ссылка на которую добавлена исключительно через Диспетчер тегов?
- Проиндексирует ли страницу, ссылка на которую есть только в разметке JSON-LD, внедренной на страницу Диспетчером тегов?
Если вам интересны ответы на эти вопросы и инструкции по внедрению — читайте дальше.
Коротко: все эти тесты прошли успешно — правда, в некоторых случаях влиять на результаты поиска они начали лишь через продолжительное время.
Замена тегов Title и Meta Description через Диспетчер тегов
Теги Title и Meta Description на англоязычной версии нашей страницы https://www.searchviu.com/en/ выглядят в исходном HTML-коде так:
Мы использовали следующий скрипт в Пользовательском теге в Диспетчере тегов для замены исходных Title и Description, чтобы в коде, получившемся после загрузки страницы и исполнения скриптов (“rendered HTML”), текст в них отличался.
В Title мы только заменили буквы в некоторых словах на заглавные, в Description заменили несколько слов.
Оригинальный Title и Description по-прежнему видно в исходном коде страницы, но если вы посмотрите на измененный HTML после загрузки в «Инструментах разработчика» в браузере Chrome, то увидите, что Диспетчер тегов (GTM) изменил их содержимое.
Спустя восемь дней после публикации изменений в GTM Google начал показывать измененные Title и Description в результатах поиска вместо тех, что присутствуют в исходном коде страницы.
Не сказать, что мы сильно удивились этому результату, поскольку прошлый эксперимент показал, что Google использует для получения тега hreflang HTML-код после рендеринга, игнорируя исходный код. Мы ожидали такого же поведения поисковой системы для тегов Title и Meta Description.
То, что изменения в результатах поиска произошли спустя восемь дней, тоже нас не удивило, поскольку Google производит рендеринг страниц не так часто, как их обход. Чтобы делать более уверенные заявления про разницу в периодичности обхода и рендеринга страниц, нужно проводить отдельное исследование, так что это пока просто примечание.
Давайте попробуем вещи посложнее — например, noindex.
Удаление страницы из индекса с помощью тега meta noindex, внедренного через GTM
Когда мы приступали к этому эксперименту, мы нашли на сайте несколько страниц, индексацию которых хотели бы запретить.
Следующий скрипт, добавленный в Пользовательский тег в GTM и выполняемый при загрузке страницы, добавит meta noindex на наши страницы, тем самым запретив добавлять их индекс.
Потом мы ждали долго, очень долго, уже потеряли надежду. Google просто это игнорировал.
Должен признать, что я не очень внимательный экспериментатор. Не могу точно сказать, сколько времени прошло с момента внедрения — где-то между шестью неделями и тремя месяцами. Но однажды Google произвел рендеринг этих страниц и выкинул все пять штук из индекса.
Вот поисковый запрос, который я использовал для скриншота, на случай, если вы хотите проверить самостоятельно:
site:searchviu.com/en/we-are-going-to-miss-you/ OR site:searchviu.com/de/wir-werden-dich-vermissen/ OR site:searchviu.com/en/author/ana-cidre/ OR site:searchviu.com/en/thank-getting-contact/ OR site:searchviu.com/en/embed/
Итак, это тоже сработало, но заняло гораздо больше времени, чем эксперимент с Title и Description. Наша гипотеза сейчас в том, что рендеринг менее важных страниц сайта происходит значительно реже. Но, как я написал выше, нужно отдельно исследовать различия в частоте обхода и рендеринга страниц, прежде чем делать какие-то выводы.
Давайте посмотрим, как наш метод сработает с тегом Canonical.
Добавление тега Canonical через Диспетчер тегов Google
Использовать теги Canonical сложно, поскольку, независимо от реализации, Google может их проигнорировать, если есть другие сигналы, конфликтующие с содержимым тега (например, трафик на неканоническую версию страницы с других каналов существенно выше, чем на ту, которую вы указали как каноническую — прим. пер.). Поэтому нам нужно найти для эксперимента такие страницы, где Google очевидно должен учесть содержимое данного тега.
Одно из важных условий правильного использование тега Canonical — совпадение контента канонической и неканонической версий страницы. По этой причине мы решили на странице автора добавить тег Canonical, который указывает на URL главной страницы блога. Все содержимое этих страниц совпадает.
Вот как выглядит код в GTM:
Если вкратце: сработало просто отлично, но заняло столько же времени, сколько эксперимент с тегом noindex.
Результаты поиска по запросу [eoghan henn searchviu] до того, как мы добавили пользовательский скрипт c Canonical в GTM.
И вот текущие результаты. Страница исчезла из выдачи (еще одно интересное наблюдение –каноническая страница не стала ранжироваться по этому запросу так же высоко).
Итак, Google учитывает содержимое тега Canonical, добавленного через GTM (если вы используете его по назначению).
Я знаю, что многих интересует, как обстоят дела со ссылками, добавленными через JavaScript.
Поддерживает ли Google внутренние ссылки, добавленные через GTM?
Единственное, что нам было очень интересно перед запуском этого эксперимента, это то, обходит ли Google внутренние ссылки, которые отсутствовали в изначальном исходном HTML-коде, и были добавлены только JavaScript’ом через GTM. Поэтому мы запустили следующий тест.
Для начала мы создали на нашем сайте на WordPress две одинаковых страницы: на одну из них мы добавили ссылку через GTM, а вторая не имела внутренних ссылающихся страниц.
Зачем мы создали вторую страницу? Если первая проиндексируется, мы должны быть уверены, что это произошло из-за ссылки, поставленной через GTM, а не по какой-то еще причине.
Мы убедились, что страница не попадет в XML-карту сайта, не будет отправлен пинг в сервисы или что-то подобное. Но для чистоты эксперимента мы создали еще одну страницу, контрольную. Результат эксперимента будет считаться положительным только в том случае, если первая страница проиндексируется, а вторая нет.
Может, я не такой уж невнимательный экспериментатор.
Давайте посмотрим, как это выглядит в GTM. Мы взяли не самую важную страницу нашего сайта, нашли ссылку, на которую никто не кликнет (надеемся), и использовали следующий код для замены URL’а на URL первой из наших тестовых страниц.
Вот результат. Страница, ссылка на которую была лишь в коде, внедренном через GTM, проиндексировалась. Контрольная страница не попала в индекс. Как и в предыдущих случаях, результаты эксперимента появились нескоро (прошло около двух месяцев).
Если вас заинтересовало слово «-sameas» в поисковом запросе, прочитайте следующую часть этой статьи. Мы создали еще одну страницу, ссылка на которую содержится только в разметке JSON-LD, также добавленной на страницу через GTM, чтобы посмотреть, как Google отреагирует на эту ситуацию.
Проиндексирует ли Google URL, который встречается только в разметке JSON-LD, добавленной через GTM?
Как вы знаете, я действительно внедряю структурированную разметку (schema.org) в формате JSON-LD через Диспетчер тегов Google. Помимо этого, ранее я заметил, что URL одного домена, который используется в скрипте JSON-LD другого домена, показывается у первого как внешняя ссылка в Google Search Console. Google странно поступает с информацией, содержащейся в структурированных данных, и я хотел исследовать этот момент подробнее.
Мы решили создать еще одну тестовую страницу, как в предыдущем эксперименте, но добавить ссылку на нее только в скрипте JSON-LD и нигде больше. Вот как это настраивается в Диспетчере тегов:
И это тоже сработало. Google проиндексировал страницу, ссылка на которую содержится только в JSON-LD-скрипте на первой тестовой странице.
Итак, скрипты JSON-LD являются еще одним источником ссылок для ботов Google.
Заключение: в GTM можно добавлять что угодно, но для учета изменений может понадобиться время
Результаты проведенных тестов показали, что Google учитывает теги Title, Description, Noindex и Canonical, добавленные или модифицированные с помощью Диспетчера тегов. Исходный код документа игнорируется; используется HTML, получившийся после рендеринга страницы.
Кроме того, через Диспетчер тегов можно добавлять внутренние ссылки, и Google их проиндексирует. Даже если они добавлены только в скрипты JSON-LD.
К сожалению, этот эксперимент не был задуман как исследование скорости реагирования Google на изменения. Мы не настраивали мониторинг, чтобы проверять появление изменений на регулярной основе. Мы знаем, что изменения Title и Description показались через восемь дней, остальное заняло примерно два месяца.
Кажется очевидным, что Google значительно реже производит рендеринг страниц, чем сканирует исходный HTML-код. Отдельное исследование на эту тему было бы очень ценным.
Прошлые SEO-тесты JavaScript, которые не учитывали огромные задержки до появления результатов, могли иметь отрицательный результат потому, что проводились недостаточно долго. Особенно если использовались новые страницы, созданные только для этих экспериментов. Вероятно, рендеринг важных страниц (например, главной страницы нашего блога в эксперименте) происходит гораздо чаще, чем менее важных (таких, как все остальные страницы в проводимых тестах).
Надеемся, что наш небольшой JavaScript SEO-эксперимент оказался для вас полезным, и другие специалисты настроят аналогичные тесты, чтобы SEO-индустрия могла больше узнать о том, как Google работает со страницами, содержимое которых зависит от JS.
