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

1. Почему большие сайты представляют собой проблему для SEO
2. Бюджет сканирования
3. Выявление технических проблем SEO с большими сайтами
4. Общие технические проблемы SEO с большими сайтами
5. Карта сайта ошибок и предупреждений
6. Низкая скорость страницы и время отклика сервера
7. Ошибки Soft 404
8. Хард 404 ошибки
9. Дублированный контент
10. Недостаток канонизации
11. URL структуры, субдомены и протоколы
12. Фасетная навигация, фильтры и внутренний поиск
13. Содержание, разбитое на страницы
14. В заключение

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

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

Почему большие сайты представляют собой проблему для SEO

Крупные веб-сайты создают проблемы для веб-мастеров и SEO-специалистов по ряду причин;

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

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

Бюджет сканирования

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

Однако в конце 2016 года Гари Иллиес из Google написал эта почта , чтобы обеспечить ясность в отношении бюджета обхода. В заключение он сказал;

«Приоритизация того, что сканировать, когда и сколько ресурсов сервер, размещающий сайт, может выделить для сканирования, более важен для больших сайтов или тех, которые автоматически генерируют страницы на основе параметров URL»,

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

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

Бюджет сканирования - это «объединение скорости сканирования и спроса на сканирование». Google определяет бюджет сканирования как «количество URL-адресов, которые робот Googlebot может и хочет сканировать».

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

Выявление технических проблем SEO с большими сайтами

Чтобы выявить и проанализировать проблемы, вам потребуется доступ к нескольким вещам, первым из которых является Google Search Console. В GSC есть различные разделы, которые станут вашим лучшим другом при анализе технической производительности SEO, а именно области индексации и сканирования интерфейса.

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

Здесь, в Impression, наш инструмент выбора DeepCrawl ,

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

Общие технические проблемы SEO с большими сайтами

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

Карта сайта ошибок и предупреждений

Если ваша цель состоит в том, чтобы Google сканировал каждую важную страницу на вашем веб-сайте, то вам нужно дать этим страницам максимальный шанс быть обнаруженными.

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

Если это не так, то робот Googlebot, скорее всего, столкнется с ошибками и в результате не сможет сканировать ваши страницы, на которые ссылаются.

Низкая скорость страницы и время отклика сервера

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

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

Конкретные ошибки, которые вы можете увидеть, включают:

• Тайм-аут подключения
• Сбой соединения
• В соединении отказано
• Нет ответа
• Усеченный ответ
• Сброс соединения
• Усеченные заголовки
• Тайм-аут

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

Также используйте много инструментов скорости страницы, таких как Google Page Speed ​​Insights , Тест скорости сайта Pingdom а также Тест веб-страницы выявить любые возможности для оптимизации скорости сайта.

Ошибки Soft 404

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

Чаще всего эти страницы 302 (временно) перенаправляются на окончательный URL-адрес местоположения, который затем в конечном итоге возвращает код состояния 200 OK.

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

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

Google рекомендует настроить сервер так, чтобы он всегда возвращал код ответа 404 (не найден) или 410 (пропал) в ответ на запрос несуществующей страницы.

Обеспечение того, чтобы ваша страница 404 была полезной и интересной, поможет эффективно направлять пользователей обратно на ваши сайты.

Хард 404 ошибки

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

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

Коды состояния 404 должны всегда отслеживаться, и, по сути, вам нужно будет решить, стоит ли исправлять 404. Я бы предложил расставить приоритеты по вашим 404 ошибкам и исправить те, которые нужно исправить. Любые URL, которые не требуют перенаправления, будут просто выпадать из индексации Google по мере их обнаружения.

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

Дублированный контент

Большой веб-сайт = большая вероятность дублирования проблем с контентом.

Природа дублирования контента обычно делится на две основные категории;

• Проблемы с технической сборкой сайта
• Физическое содержание на рассматриваемых страницах.

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

Недостаток канонизации

Канонический тег (он же «rel canonical») - это метод уведомления сканеров поисковых систем о том, что конкретный URL-адрес представляет собой главную копию страницы, и он полезен в тех случаях, когда для поисковых систем может возникнуть путаница, вызванная дублирующимися или похожими URL-адресами.

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

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

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

URL структуры, субдомены и протоколы

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

Если это происходит, то каждый URL будет рассматриваться как уникальный URL - добавьте поддомены и протоколы http, которые неправильно настроены (www против non-www и http против https), и 1 URL может привести к 5 или 6 дубликатам.

Чтобы избежать дублирования вопросов контента такого характера;

• Убедитесь, что http 301 перенаправляет на https
• Выберите версию вашего сайта с www или без www в качестве основной и установите ее в консоли поиска Google, а также убедитесь, что один 301 перенаправляет на другой.
• Подготовьте URL-адреса для загрузки как с косыми чертами, так и без них, но снова убедитесь, что один 301 перенаправляет на другой
• Убедитесь, что ваши канонические URL-адреса ссылаются на единственную правильную версию URL-адреса.

Фасетная навигация, фильтры и внутренний поиск

Канонические URL-адреса помогут устранить проблемы с дублированием контента, если одна страница доступна / доступна в нескольких подпапках.

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

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

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

Существует несколько вариантов решения проблем с дублирующимся содержимым, подробно рассмотренных в этом посте на Мос Подводя итог, наиболее распространенными являются (а иногда и комбинации);

• Noindex, следите за гранеными URL
• Каноникализация граненых URL-адресов обратно на страницу основной категории
• Блокировка сканирования этих URL-адресов в файле robots.txt для экономии бюджета сканирования

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

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

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

Содержание, разбитое на страницы

Разбиение на страницы распространено на крупномасштабных сайтах и ​​происходит, когда контент охватывает номера страниц как часть классифицированной серии.

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

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

Для оптимизации эффективности сканирования, где это возможно, я всегда рекомендую использовать Rel = ”Prev” / ”next”, чтобы указать связь между URL-адресами компонентов.

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

Пример:

Страница 1:
<link rel = ”next” href = ”www.site.com/page2.html”>

Страница 2:
<link rel = ”prev” href = »www.site.com/page1.html»>
<link rel = ”next” href = ”www.site.com/page3.html”>

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

В заключение

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

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

Похожие

Комментарии