1. информация: поисковый оператор
2. & filter = 0 добавлен в поисковый URL Google
3. сайт: поисковый оператор
4. ключевое слово site: domain.com
5. Статический против динамического
6. Проверьте перенаправления и ответы заголовка
7. Проверьте наличие нескольких наборов тегов
8. Изменить UA на Googlebot
9. Robots.txt
10. Избавь себя от головной боли
11. Подводя итоги

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

информация: поисковый оператор

Часто [info: https: //www.domain.com/page] может помочь вам диагностировать различные проблемы. Эта команда сообщит вам, проиндексирована ли страница и как она проиндексирована. Иногда Google предпочитает складывать страницы вместе в своем индексе и рассматривать два или более дубликатов как одну и ту же страницу. Эта команда показывает вам канонизированную версию - не обязательно ту, которая указана канонический тег , а скорее то, что Google рассматривает как версию, которую они хотят проиндексировать.

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

Время от времени вы можете увидеть это и при взломе SERP, когда поиск [info:] на одном домене / странице фактически покажет совершенно другой домен / страницу. Это произошло во время конкурса SEO-героя Wix в начале этого года, когда более сильный и более авторитетный домен скопировал мой сайт и смог некоторое время занять мою позицию в поисковой выдаче. Дэн Шарп также сделал это с SEO руководство Google в начале этого года.

& filter = 0 добавлен в поисковый URL Google

Добавление & filter = 0 в конец URL-адреса в поиске Google удалит фильтры и покажет вам больше веб-сайтов в наборе рекомендаций Google. Когда вы добавляете это, вы можете увидеть две версии страницы, что может указывать на проблемы с дублирующимися страницами, которые не были объединены; например, они оба могут сказать, что они являются правильной версией, и у них есть сигналы для поддержки этого.

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

сайт: поисковый оператор

Поиск [site: domain.com] может выявить множество знаний о веб-сайте. Я бы искал страницы, которые проиндексированы способами, которых я не ожидал, например, с параметрами, страницами в разделах сайта, о которых я, возможно, не знаю, и любыми проблемами с проиндексированными страницами, которых не должно быть (например, сервер разработки) ,

ключевое слово site: domain.com

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

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

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

Статический против динамического

Когда вы имеете дело с JavaScript (JS), важно понимать, что JS может переписать HTML страницы. Если вы смотрите на источник просмотра или даже кеш Google, то на что вы обращаете внимание - это необработанный код. Это не очень хорошие представления о том, что на самом деле может быть включено после обработки JS.

Используйте «inspect» вместо «view-source», чтобы увидеть, что загружено в DOM (объектная модель документа), и используйте «Fetch and Render» в Google Search Console вместо кеша Google, чтобы получить лучшее представление о том, как Google на самом деле видит страница.

Не говорите людям, что это неправильно, потому что это выглядит смешно в кеше или что-то не в источнике; это может быть ты, кто не прав. В некоторых случаях вы можете заглянуть в источник и сказать, что что-то правильно, но при обработке что-то в разделе <head> разрывается и приводит к преждевременному завершению, выбрасывая множество тегов, таких как canonical или hreflang, в раздел <body>, где они не поддерживаются.

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

Проверьте перенаправления и ответы заголовка

Вы можете выполнить любую из этих проверок с помощью инструментов разработчика Chrome, или, чтобы упростить ее, вы можете проверить такие расширения, как Путь перенаправления или же Трассировка перенаправления ссылки , Важно видеть, как обрабатываются ваши перенаправления. Если вас беспокоит определенный путь и объединяются ли сигналы, проверьте отчет «Ссылки на ваш сайт» в консоли поиска Google и найдите ссылки, которые переходят на страницы ранее в цепочке, чтобы увидеть, есть ли они в отчете для на странице и отображается как «Через эту промежуточную ссылку». Если это так, то безопасная ставка - Google считает ссылки и объединяет сигналы до последней версии страницы.

Что касается ответов заголовков, все может стать интересным. В редких случаях вы можете увидеть здесь канонические теги и теги hreflang, которые могут конфликтовать с другими тегами на странице. Перенаправление с использованием HTTP-заголовка также может быть проблематичным. Я не раз видел, как люди устанавливали «Location:» для перенаправления без какой-либо информации в поле, а затем перенаправляли людей на страницу, скажем, с помощью перенаправления JS. Ну, пользователь переходит на нужную страницу, но робот Googlebot сначала обрабатывает Location: и уходит в пропасть. Они перенаправлены в ничто, прежде чем они смогут увидеть другой перенаправления.

Проверьте наличие нескольких наборов тегов

Многие теги могут находиться в нескольких местах, например, заголовок HTTP, раздел <head> и карта сайта. Проверьте наличие любых несоответствий между тегами. Ничто не мешает множеству наборов тегов на странице. Может быть, ваш шаблон добавил мета-тег robots для индекса, тогда у плагина был один набор для noindex.

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

Изменить UA на Googlebot

Иногда вам просто нужно посмотреть, что видит Google. Есть много интересных вопросов, связанных с маскировкой, перенаправлением пользователей и кэшированием. Вы можете изменить это с помощью Chrome Developer Tools (инструкции Вот ) или с плагином, как Переключатель User-Agent , Я бы порекомендовал, если вы собираетесь сделать это, что вы делаете это в режиме инкогнито. Вы хотите проверить, что робот Google не перенаправляется куда-то - как, может быть, они не могут видеть страницу в другой стране, потому что они перенаправляются на основе IP-адреса США на другую страницу.

Robots.txt

Проверьте свои robots.txt за все, что может быть заблокировано. Если вы заблокируете обход страницы и добавите каноническое на этой странице на другую страницу или тег noindex, Google не сможет сканировать страницу и не сможет увидеть эти теги.

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

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

Избавь себя от головной боли

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

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

Подводя итоги

В сложной среде может быть много команд, работающих над проектами. У вас может быть несколько систем CMS, инфраструктур, CDN и так далее. Вы должны предполагать, что все изменится, и все сломается в некоторый момент. Есть так много точек отказа, что делает работу технического SEO интересной и сложной.

Мнения, выраженные в этой статье, принадлежат автору гостя и не обязательно относятся к Search Engine Land. Штатные авторы перечислены Вот ,

Об авторе