SEO продвижение > Аудит сайта самостоятельно > Аудит сайта

Технические проблемы сайта

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

1. Адреса сайтов в верхнем и нижнем регистре

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

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

Решение:

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

2. Несколько версий главной страницы

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

www.example.com/default.aspx

Результат? Страница в наличии! Это дубликат главной страницы, который поисковые системы обычно могут найти с помощью навигации или XML карты сайта.

Для других платформ также можно сгенерировать похожие адреса:

www.example.com/index.html
www.example.com/home

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

Решение:

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

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

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

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

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

3. Параметры запроса в конце адреса

Как правило, такая проблема появляется на коммерческих сайтах, которые управляются базами данных. Причина в том, что коммерческие сайты загружают много данных по продукту с применением фильтров по различным показателям. Вот пример сайта Go Outdoors (не клиент):

В этом случае переходы пользователей относительно дружественные с точки зрения СЕО, но довольно часто вы можете в конечном итоге получить, например, такой адрес:

www.example.com/product-category?colour=12

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

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

www.example.com/product-category?colour=12&size=5
www.example.com/product-category?size=5&colour=12

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

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

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

Решение:

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

Мы начнем с того, что определим, какие страницы вы хотите отдать на сканирование и индексирование в Google. Решение должно быть основано на ваших ключах, и вы должны использовать перекрестные ссылки всех атрибутов базы данных с вашими ключевыми словами. Давайте продолжим на примере Go Outdoors:

Вот наши основные ключевые слова:

• Waterproof jackets
• Hiking boots
• Women's walking trousers

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

• Размер (напр. big)
• Цвет (напр. black)
• Цена (£ 49.99)
• Бренд (напр. North Face)

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

Узнав все это, вы обнаружите, что для ключей, которые имеют слова "North Face" + "waterproof jackets" потенциал поиска намного выше, чем у других ключей. Это значит, что если вы захотите просканировать и проиндексировать страницу для "North Face" + "waterproof jackets" вы также захотите убедиться, что база данных атрибутов дружественна в отношении СЕО, и вы, вместо "waterproof-jackets/?brand=5" выберете "waterproof-jackets/north-face/". Вы, несомненно, захотите убедиться, что данные адреса являются частью структуры вашего сайта и обеспечивают приемлемый уровень PageRank, что позволяет пользователям легко находить вашу страницу.

С другой стороны, вы возможно обнаружите, что комбинация ключей "North Face" и "Black" не имеет достаточного потенциала поиска (например "black North Face jackets"). Это означает, что вы, возможно, не захотите сканировать и индексировать страницу с такими атрибутами.

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

Если адрес уже проиндексирован, то просто добавьте структуру адреса в ваш текстовый файл robot.txt. Воспользуйтесь RegEx (регулярными выражениями) чтобы выполнить эту задачу. Проверьте все внимательно, в противном случае, вы случайно внесете ошибки в файл. Убедитесь, что вы используете Fetch как функцию Google в инструментах вебмастера (Webmaster Tools).

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

Если адреса проиндексированы, то вам, скорее всего, необходима заплатка для решения данной проблемы: тег "rel=canonical". К сожалению, вам не часто придется работать на сайте, который находится в процессе разработки. Так что исправить проблему, описанную выше, будет невозможно. В таком случае, тэг “rel=canonical” служит заплаткой, которая позволит решить проблему несколько позднее. Вы захотите добавить тэг “rel=canonical” к адресу, который вы не хотите индексировать и вы укажите наиболее релевантный адрес для индексации.

4. Программные ошибки 404

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

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

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

Решение:

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

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

Вы также можете выполнить ручную проверку, перейдя на битый адрес на вашем сайте (например, www.example.com/5435fdfdfd) и посмотреть, какой код статуса вы получаете. Web Sniffer, инструмент для проверки состояния кода, который мне очень нравится, или вы можете использовать инструмент Ayima, если вы используете Google Chrome.

5. Редиректы 302 вместо редиректов 301

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

Решение:

Для того чтобы обнаружить адреса с редиректом 302, я рекомендую использовать глубокое сканирование, например сервис Screaming Frog или IIS SEO Toolkit. С помощью фильтра, вы сможете проверить какие адреса должны иметь редирект 302 или редирект 301.

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

6. Испорченные и устаревшие карты сайтов

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

Bing заявил, что у них есть порог для "грязи" в карте сайта, и если порог превышен, то они больше не будут доверять сайту.

Решение:

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

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

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

Несколько необычных технических проблем

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

7. Ошибки в файле

Robots.txt

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

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

Решение:

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

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

8. Невидимые символы в файле robots.txt

Я недавно сделал технический аудит для одного из моих клиентов, и заметил предупреждение в инструментах для веб-мастеров Google о том, что «Синтаксис не был понят" в одной из строк. Когда я пересмотрел файл и проверил еще раз, все шло хорошо. Я показал проблему Тому Энтони, который проверил файл с помощью командной строки, и он поставил диагноз проблемы: невидимый символ каким-то образом попал в файл.

Выглядел я довольно глупо в ситуации повторного открытия файла и обнаружения проблемы!

Решение:

Исправить это довольно просто. Просто перепишите файл robots.txt и запустить его через командную строку, чтобы снова проверить.

9. Google сканирует адреса в кодировке Base64

Мы столкнулись с интересной проблемой, которую тоже обнаружил Том. Один из наших клиентов увидел увеличение количества ошибок 404, о которых сообщается в инструментах веб-мастера Google. Мы обнаружили, что почти все ошибки были связаны с адресами в следующем формате:

/aWYgeW91IGhhdmUgZGHkNCmdldCBhIGxpZmU=/

Инструменты веб-мастера покажут вам, откуда они появляются. Мы прошли всю цепочку к предполагаемой странице, на который генерировался такой адрес. Но как мы ни старались, найти мы ничего не смогли. После долгих проверок, мы все-таки заметили, что это были маркеры аутентификации, которые генерируется приложением Ruby on Rails для предотвращения перекрестных запросов сайта. Таких маркеров было несколько, и Google пытался их просканировать!

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

Решение:

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

10. Неправильно настроенные сервера

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

В норме заголовок 'Accept' отправляется клиентом (вашим браузером) в состоянии, какие типы файлов он понимает, и это очень редко изменятся сервером. Сервер при отправке файла, отправляет заголовок "Content-Type" для указания типа файла HTML / PDF / JPEG / или что-то еще.

Сервер клиента (Nginx) возвращал "Content-Type" который был зеркалом первого файла типов содержащихся в клиентском 'Accept' заголовке. Если отправляете 'Accept' заголовок, который начинается "text/html," это значит, что сервер отправит назад точно такой же "Content-Type" заголовок. Такое вот своеобразное поведение, но оно незаметно, поскольку браузеры почти всегда, отправляют "text/html," как свой 'Accept' заголовок.

Однако Googlebot когда сканирует, отправляет "Accept: */*" (принимаются любые значения).

Я обнаружил, что если я отправлю “*/*” заголовок, это приведет к падению сервера, поскольку “*/*” не является валидным "Content-Type" заголовком и сервер отправит сообщение об ошибке.

Изменение агента вашего браузера на Googlebot не влияет на HTTP-заголовки, и такие средства, как Web-Sniffer также не посылают HTTP-заголовки, как это делает Googlebot, так что вы никогда не заметите такой проблемы с ними!

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


Меню сайта

Технические проблемы сайта
Технические проблемы сайта