Решение технических проблем SEO

Решение технических SEO часто расстраивает, особенно когда вам приходится снова и снова решать проблему одного и того же сайта. И я думаю, я не одинок; Есть несколько сайтов, страдающих от этой проблемы. В этом посте я попытался обрисовать некоторые распространенные проблемы, с которыми мне пришлось столкнуться с помощью эффективных решений.

Проблема № 1: Прописные URL-адреса против строчных URL-адресов

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

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

Проблема № 2: Несколько версий главной страницы

Это также более распространено на веб-сайтах .NET, но также происходит и на других платформах. Во время аудита вашего сайта, проверьте, есть ли дубликаты версии вашей домашней страницы. Чтобы проверить это, просто введите www.yourwebsite.com/ default.aspx ИЛИ www.yourwebsite.com/ index.html ИЛИ www.yourwebsite.com/home

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

Решение. Решение этой проблемы часто зависит от игры в догадки, поскольку разные платформы генерируют разные структуры URL, что затрудняет поиск этих страниц. Лучшее решение - это сканировать ваш веб-сайт и исследовать его в CSV. Теперь отфильтруйте сканирование по столбцу заголовка META, чтобы найти заголовок вашей домашней страницы. Таким образом, вы можете легко найти дубликаты страниц домашней страницы вашего сайта. Кроме того, вы можете добавить перенаправление 301 на эти дубликаты страниц, указывающие на вашу правильную страницу. Я также видел, как многие решали эту проблему с помощью тега rel = canonical.

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

Проблема № 3: Софт 404 ошибки

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

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

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

Как решить:

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

Чтобы найти программные 404, вы можете использовать функцию в Google Webmaster Tools, которая расскажет вам о тех, которые Google обнаружил:
Вы также можете выполнить ручную проверку, перейдя по неработающему URL на вашем сайте (например, www.example.com/5435fdfdfd) и узнав, какой код статуса вы получаете. Инструмент, который мне действительно нравится для проверки кода состояния, - это Web Sniffer, или вы можете использовать инструмент Ayima, если вы используете Google Chrome.

302 редиректа вместо 301 редиректа

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

Как решить:

Чтобы найти 302 перенаправленных URL-адреса, я рекомендую использовать глубокий сканер, такой как Screaming Frog или IIS SEO Toolkit. Затем вы можете отфильтровать по 302-ым и проверить, действительно ли они равны 302-ым, или вместо них должны быть 301-ые.

Чтобы решить эту проблему, вам нужно попросить разработчиков изменить правило, чтобы вместо редиректа 302 использовалось перенаправление 301.

Похожие

Комментарии