19 распространенных технических проблем SEO (с рекомендуемыми решениями)

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

Ниже перечислены наиболее распространенные технические проблемы SEO:

1. Правила без учета регистра в robots,txt
2. Дублирование URL в верхнем и нижнем регистре
3. HTTP 302 перенаправляет на HTTPS
4. Канонические URL-адреса, влияющие на внутренние ссылки
5. Канонические URL-адреса, ссылающиеся на URL-адреса 404
6. Несколько канонических тегов
7. Дублирование домашней страницы
8. Мобильная и десктопная версии сайтов отличаются
9. Обнаружение международного IP
10. Дублирование международного веб-сайта
11. XML-карта сайта, включая исторические URL-адреса и промежуточные URL-адреса
12. Промежуточный веб-сайт индексируется, что приводит к дублированию
13. Внутренний поиск индексируется
14. Параметры, вызывающие дублирование
15. Дублирование URL продукта
16. Глубина веб-сайта
17. JavaScript
18. Неправильное использование Meta Robots NOINDEX
19. Мягкие 404 страницы

1. Правила без учета регистра в robots,txt

Проблема:

При проведении технического SEO-аудита мы часто обнаруживаем, что запрещающие правила в файле robots.txt не учитывают ни прописные, ни строчные буквы.

Например, на сайтах электронной коммерции пути к корзине часто начинаются как с /basket/, так и с /Basket/, но в robots.txt, как правило, включается только путь в нижнем регистре. Это означает, что URL-адреса с /Basket/ по-прежнему будут индексироваться, что приведет к дублированию контента, чего следует избегать для улучшения индексации вашего веб-сайта в поисковых системах.

Правила robots.txt:

Запретить: /корзина/

Запретить: /корзина/*

Решение:

Проведите аудит своего веб-сайта и проверьте, есть ли версии пути, которые необходимо заблокировать, как в верхнем, так и в нижнем регистре. Вы можете сделать это с помощью поискового робота, такого как наши друзья из DeepCrawl. Если на веб-сайте активны обе версии, добавьте второе правило в robots.txt, чтобы обеспечить блокировку пути в верхнем регистре. Например, Запретить: /Корзина/*

Если у вас нет доступа к веб-сканеру, поиск по протоколу сайта может быть очень полезен, чтобы увидеть, индексируются ли как прописные, так и строчные версии.

2. Дублирование URL-адресов в верхнем и нижнем регистре

Проблема:

Распространенной проблемой, которую мы обнаруживаем, является дублирование URL-адресов без учета регистра, на которые ссылаются на веб-сайте, и Google видит, что это два разных URL-адреса. Например:

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

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

Решение:

Мы рекомендуем настроить правило на уровне сервера, согласно которому все URL-адреса в верхнем регистре перенаправляются на строчные через переадресацию 301. Это защитит веб-сайт от любого дублирования в будущем, когда на него ссылаются как в верхнем, так и в нижнем регистре URL-адреса.

Добавление правила перенаправления 301 также укрепит любой ссылочный вес, когда внешний сайт может по ошибке ссылаться на ваш сайт через заглавную букву.

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

3. HTTP 302 перенаправляет на HTTPS

Проблема:

Компании часто переводят свои веб-сайты на защищенные URL-адреса HTTPS, но они не всегда реализуют правило перенаправления 301, а вместо этого реализуют перенаправление 302, поэтому теоретически это сообщает поисковым системам, что HTTP-версия URL-адреса была перемещена только временно, а не навсегда. Это может снизить ссылочный вес и общий авторитет вашего веб-сайта, поскольку URL-адреса HTTP, которые со временем приобрели обратные ссылки, не будут полностью передавать ссылочный вес версии HTTPS, если не будет перенаправления 301.

Решение:

Мы рекомендуем настроить правило на уровне сервера, при котором все URL-адреса HTTP 301 перенаправляют на версию HTTPS.

4. Канонические URL-адреса, влияющие на внутренние ссылки

Проблема:

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

Кроме того, каноническая страница продукта не содержит хлебных крошек, которые влияют на внутренние ссылки на веб-сайте.

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

Решение:

Чтобы помочь индексировать канонические URL-адреса, веб-сайты должны:

Добавьте канонические URL-адреса в карту сайта XML, а не другие варианты URL-адресов.

Внутренние ссылки на версии канонических URL-адресов в модулях внутренних ссылок на уровне всего сайта, таких как «популярные продукты».

Добавьте основную структуру хлебных крошек на страницу канонического URL.

5. Канонические URL-адреса, ссылающиеся на URL-адреса 404

Проблема:

Канонические URL-адреса иногда ссылаются на URL-адреса 404, но это посылает смешанные сигналы для поиска.

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

Решение:

Во-первых, вы должны установить, должен ли канонический URL быть 404 или его следует восстановить. Если он восстановлен, проблема устранена, однако, если канонический URL-адрес должен быть 404, вам следует выбрать новый канонический URL-адрес или обновить канонический, чтобы он ссылался на себя.

6. Несколько канонических тегов

Проблема:

В HTML-коде веб-страницы иногда могут быть обнаружены два канонических тега. Это может отправить противоречивые сообщения в поисковую систему, и только первое каноническое будет учитываться и использоваться.

Решение:

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

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

7. Дублирование главной страницы

Проблема:

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

www.example.com

www.example.com/home

www.example.com/index.html

www.example.com/home.html

Решение:

Если на вашем веб-сайте несколько URL-адресов главной страницы, мы рекомендуем настроить переадресацию 301, при которой все дублирующиеся версии перенаправляют на главную версию домашней страницы.

8. Мобильная и десктопная версии сайтов отличаются

Проблема:

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

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

Решение:

Мобильная версия сайта должна содержать тот же контент, что и настольная версия, а отсутствующий контент должен быть добавлен на мобильный сайт.

9. Международная регистрация IP

Проблема:

Для веб-сайтов, на которых реализовано перенаправление по географическому IP-адресу, наиболее распространенная проблема заключается в том, что реализация перенаправляет для всех пользователей, включая ботов.

Googlebot обычно сканирует с IP-адреса в США, и если боты перенаправляются в зависимости от географического положения, то Googlebot будет сканировать и индексировать только версию веб-сайта для США. Это предотвратит сканирование и индексацию других географических версий сайта.

Кроме того, это может вызвать проблемы с разметкой схемы ценообразования продуктов на сайтах электронной коммерции, где цены обновляются в зависимости от географического положения, поскольку на всех рынках будет отображаться только цена в США. Например, в приведенном ниже фрагменте показаны цены для США, поступающие на британскую версию веб-сайта в Великобритании.

Решение:

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

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

Это полезная функция UX, если пользователь попал на неправильную международную версию веб-сайта. Всплывающее окно будет отображаться на основе обнаружения IP-адреса, например, если пользователь переходит на веб-сайт в США с IP-адреса в Великобритании, появится баннер, сообщающий пользователю, что сайт в Великобритании может быть более подходящим.

10. Дублирование международного веб-сайта

Проблема:

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

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

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

Решение:

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

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

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

Посетите нашу страницу международных услуг SEO, если вы планируете расширение международного веб-сайта или у вас возникли проблемы с вашими международными веб-сайтами.

11. XML-карта сайта, включая исторические URL-адреса и промежуточные URL-адреса.

Проблема:

Интересная проблема, с которой мы сталкиваемся чаще, чем вы думаете, это веб-сайты со старыми URL-адресами в своих XML-картах сайта или промежуточными URL-адресами, которые каким-то образом втискиваются в XML-карту сайта.

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

Исторические URL-адреса в вашей карте сайта, которые теперь обслуживают код состояния 4xx или 3xx, могут посылать поисковым системам запутанные сигналы о том, какие страницы вы хотите просканировать или проиндексировать.

Решение:

Обязательно регулярно проверяйте свою XML-карту сайта, следя за консолью поиска и отслеживая ошибки, которые появляются, или настройте регулярное сканирование с помощью такого инструмента, как Deepcrawl.

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

12. Промежуточный веб-сайт индексируется, что приводит к дублированию

Проблема:

Удивительно, но ряд компаний индексируют свои промежуточные веб-сайты поисковыми системами, такими как Google, не специально, а по ошибке. Это может привести к значительному дублированию, поскольку промежуточный веб-сайт обычно будет копией вашей реальной среды. Благодаря простому поиску по URL-протоколу в Google есть миллионы промежуточных веб-страниц, которые можно индексировать.

Решение:

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

Пользовательский агент: *

Запретить: /

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

13. Внутренний поиск индексируется

Проблема:

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

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

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

Решение:

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

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

Шаг первый: добавьте теги NOINDEX,FOLLOW на все страницы поиска, чтобы поисковые системы могли деиндексировать эти страницы. После того, как эти страницы будут деиндексированы в течение нескольких месяцев, мы реализуем второй шаг.

Шаг второй. Добавьте внутренний каталог поиска в файл robots.txt, например Disallow: */search*.

14. Параметры, вызывающие дублирование

Проблема:

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

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

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

Решение:

Существует несколько способов предотвратить индексацию параметров и их дублирование, в том числе:

Канонизация URL-адреса параметра в чистую версию URL-адреса

Добавление правила в файл robots.txt для запрета определенных параметров

Добавление параметров в инструмент параметров URL в Search Console, который сообщает Google, что определенные параметры не следует сканировать.

15. Дублирование URL продукта

Проблема:

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

На веб-сайтах издателей документы также могут располагаться в нескольких областях, и если URL-адрес документа наследует расположение документа, создается несколько версий. Например:

Решение:

Когда мы сталкиваемся с подобным дублированием, существуют различные способы его очистки, чтобы мы могли убедиться, что правильная версия URL сканируется и индексируется.

Чтобы исправить дублирование URL-адресов, мы рекомендуем канонизировать все варианты URL-адресов продуктов до родительской или общей версии. Например:

Родительский канонический пример

женские-коллекции-платья-дневные-платья

/71hdo/белла-лула-цветочное мини-платье

будет канонизировать до:

женщины-коллекции-платья

/71hdo/белла-лула-цветочное мини-платье

Общий канонический пример:

женские-коллекции-платья-дневные-платья

/71hdo/белла-лула-цветочное мини-платье

женщины-коллекции-платья

/71hdo/белла-лула-цветочное мини-платье

канонизировал бы до

Альтернативы:

Если у вас есть доступ к разработчикам, то альтернативным решением может быть внутренняя ссылка на канонические ссылки продукта по всему веб-сайту и перенаправление 301 всех URL-адресов продуктов, которые выходят за пределы категории/подкатегории, на общий URL-адрес канонического продукта.

Это предотвратит дублирование продуктов и позволит вам ссылаться на продукты по нескольким маршрутам.

16. Глубина сайта

Проблема:

Глубина страницы — это количество кликов на определенную страницу с главной страницы веб-сайта. При проведении аудита веб-сайтов мы сталкиваемся с веб-сайтами, у которых глубина веб-сайта превышает 10. Это означает, что эти страницы находятся в 10 кликах от главной страницы!

Чем больше кликов требуется для поиска веб-страницы, тем сложнее поисковой системе найти этот URL-адрес, и более вероятно, что URL-адрес не будет пересматриваться так часто, как страницы, расположенные выше на веб-сайте.

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

Решение:

Основные способы улучшить глубину веб-сайта и обеспечить высокий приоритет приоритетных страниц в архитектуре веб-сайта включают:

Внутренние ссылки на веб-сайте, такие как рекомендуемые продукты, сопутствующие товары и избранные страницы.

Использование хлебных крошек на сайте

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

Проведение исследования ключевых слов для выявления страниц категорий верхнего уровня, на которые следует ссылаться в основной навигации веб-сайта, и добавление ссылок на приоритетные страницы.

17. Технические SEO-проблемы с JavaScript

Проблема

Многие веб-сайты сегодня будут использовать JavaScript, однако при отключении JavaScript некоторые веб-сайты не будут полностью функциональными, а ссылки могут исчезнуть и не будут обнаружены поисковыми системами. Это распространенная техническая SEO-проблема.

Часто мы видим, что модули «вам также могут понравиться» на страницах продуктов электронной коммерции не видны сканерам поисковых систем, что делает модуль внутренних ссылок излишним.

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

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

Решение:

Поработайте с командой разработчиков, чтобы попытаться создать запасной вариант JavaScript, в котором изображения по-прежнему присутствуют в исходном коде, а модули JavaScript можно сканировать через HTML.

Отличный способ проверить, как индексируется контент JavaScript, — перейти к кэшированной версии вашей веб-страницы и посмотреть, как выглядит «полная версия» страницы, а также просмотреть «текстовую версию».

18. Неправильное использование Meta Robots NOINDEX

Проблема:

Наша техническая SEO-команда провела аудит веб-сайтов и обнаружила, что теги NOINDEX были добавлены в исходный код страниц по ошибке. Кроме того, замеченные страницы, которые исторически приносили трафик, имели тег NOINDEX.

Удивительно, но проблема, которая может возникать чаще, чем вы думаете, заключается в том, что разработчики запускают промежуточные среды в реальном времени с тегом NOINDEX, все еще присутствующим в исходном коде.

В конечном итоге тег NOINDEX скажет поисковым системам не индексировать страницу и предотвратит отображение страницы в результатах поиска.

Решение:

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

Если тег NOINDEX был добавлен по ошибке, вам следует попросить разработчиков обновить исходный код и полностью удалить тег или обновить его, чтобы он читался как <meta name="robots" content="INDEX, FOLLOW">.

19. Мягкие 404 страницы

Проблема:

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

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

Есть несколько различных способов найти программные страницы 404, в том числе:

Посещение Search Console, где он помечает программные страницы 404

Сканирование вашего веб-сайта и поиск 200 страниц кода состояния с тегами заголовков «Страница не найдена»

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

Решение:

Если вы столкнулись с программными страницами 404 на своем веб-сайте, есть несколько решений, которые можно реализовать, в том числе:

301 перенаправить программные страницы 404 на соответствующую альтернативную страницу, если она доступна

Измените код состояния этих страниц на код состояния 404 или 410, но убедитесь, что ссылочный вес не будет потерян.

Если у вас возникли проблемы с вашим веб-сайтом или вам нужен технический SEO-аудит, посетите нашу страницу технических SEO-услуг, чтобы получить дополнительную информацию о том, как Semetrical может вам помочь.