Советы по устранению неполадок вашего технического SEO

Настойчивая техническая проблема SEO? У обозревателя Патрика Стокса есть несколько советов и советов, которые помогут вам диагностировать и решать некоторые распространенные проблемы.Есть много статей, заполненных контрольными списками, которые расскажут вам, какие технические поисковые запросы вы должны просмотреть на своем веб-сайте. Это не один из этих списков. То, что мне кажется нужным людям, не является другим руководством по лучшей практике, но помогает справиться с проблемами устранения неполадок.

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

Часто [info: https: //www.domain.com/page] может помочь вам диагностировать различные проблемы. Эта команда сообщит вам, проиндексирована ли страница и как она индексируется. Иногда Google пытается сворачивать страницы вместе в своем индексе и обрабатывать два или более дубликатов как одну и ту же страницу. Эта команда показывает вам каноническую версию - не обязательно ту, что указана каноническим тегом, а скорее то, что Google рассматривает как версию, которую они хотят индексировать. Если вы ищете свою страницу с этим оператором и видите другую страницу, тогда вы увидите другой рейтинг URL вместо этого в результатах - в основном Google не хотел бы иметь две одинаковые страницы в своем индексе. (Даже указанная кешированная версия - это другой URL!) Если вы делаете точные дубликаты между парными языковыми парами в тегах hreflang, например, страницы могут быть сгруппированы в одну версию и показывать неверную страницу для затронутых местоположений. Иногда вы увидите это также с помощью угона SERP, где поиск [info:] на одном домене / странице будет фактически показывать совершенно другой домен / страницу. Это произошло во время конкурса Wix's SEO Hero в начале этого года, когда более сильный и более известный домен скопировал мой сайт и смог некоторое время занять мою позицию в SERP. Дэн Шарп также сделал это с руководством Google по SEO в начале этого года.

& filter = 0 добавлен в URL-адрес Google

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

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

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

сайт: ключевое слово domain.com

Вы можете использовать [site: domain.com keyword], чтобы проверить релевантные страницы на своем сайте для другого взгляда на возможности консолидации или внутренней связи. Также интересен этот поиск, что он покажет, имеет ли ваш сайт подходящий фрагмент для этого ключевого слова. Вы можете сделать этот поиск для многих из лучших веб-сайтов, чтобы узнать, что включено в их признанные фрагменты, которые могут попытаться выяснить, что ваш сайт отсутствует или почему можно показывать по другому. Если вы используете «фразу» вместо ключевого слова, это можно использовать для проверки того, собирается ли контент Google, что удобно на веб-сайтах, которые управляются JavaScript.

Статический и динамический

Когда вы имеете дело с JavaScript (JS), важно понять, что JS может переписать HTML-страницу страницы. Если вы ищете источник просмотра или даже кеш Google, то, что вы ищете, - это необработанный код. Это не отличные представления о том, что может быть включено после обработки JS. Используйте «проверять» вместо «view-source», чтобы узнать, что загружено в DOM (Document Object Model), и используйте «Fetch and Render» в Google Search Console вместо кеша Google, чтобы лучше понять, как Google фактически видит страница. Не говорите людям, что это неправильно, потому что это выглядит забавно в кеше или что-то не в источнике; возможно, вы ошибаетесь. Могут быть моменты, когда вы смотрите в источнике и говорите, что что-то правильно, но когда обрабатывается, что-то в разделе ломается и заставляет его заканчиваться раньше, бросая в этот раздел много тегов, таких как канонические или hreflang, где они не поддерживаются. Почему эти теги не поддерживаются в теле? Вероятно, потому что это позволит захватить страницы с других сайтов.

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

Вы можете выполнить одну из этих проверок с помощью инструментов разработчика Chrome или упростить ее, вы можете проверить расширения, такие как перенаправление или трассировка переадресации ссылок. Важно видеть, как обрабатываются ваши переадресации. Если вас беспокоит определенный путь и если сигналы консолидируются, просмотрите отчет «Ссылки на ваш сайт» в Google Search Console и найдите ссылки, которые идут на страницы ранее в цепочке, чтобы узнать, находятся ли они в отчете для страницу и показана как «Через эту промежуточную ссылку». Если это так, это безопасная ставка. Google подсчитывает ссылки и консолидирует сигналы до последней версии страницы. Для ответов заголовков все может стать интересным. В редких случаях вы можете увидеть канонические теги и теги hreflang, которые могут конфликтовать с другими тегами на странице. Перенаправление с использованием заголовка HTTP может быть проблематичным. Не раз я видел, как люди устанавливали «Место:» для перенаправления без какой-либо информации в поле и затем перенаправляют людей на страницу, скажем, с помощью перенаправления JS. Ну, пользователь идет на правильную страницу, но робот Googlebot обрабатывает местоположение: сначала и переходит в пропасть. Они перенаправляются ни перед чем, пока не смогут увидеть другую переадресацию.

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

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

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

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

Robots.txt

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

Сохраните головные боли

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

Подведение итогов

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