4 проблемы технического SEO, которые не найдёт ваш софт

Рубрика: Теория и статистика | Время на чтение: 11 мин.

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

4 проблемы технического SEO, которые не найдёт ваш софт

А спонсором блога в этом месяце выступает сервис Rookee. Когда требуется комплексное поисковое продвижение, контекстная реклама на автопилоте или формирование репутации в сети – на помощь приходят Rookee!

На протяжении всей истории развития поисковой оптимизации сайтов люди спорят о плюсах и минусах использования специализированного софта.

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

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

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

Однако даже самые лучшие и современные инструменты для аудита не могут найти четыре важные технические SEO-проблемы, которые могут нанести ущерб вашим проектам:

Петля канонического редиректа.
Страницы, взломанные хакерами.
Определение JavaScript-ссылок.
Контент, скрытый за JavaScript.

Оглавление

Почему софт не находит эти проблемы

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

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

SEO-инструменты, необходимые для выявления этих проблем

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

Программа для веб-краулинга

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

Для этого можно использовать такой софт, как, например:

Screaming Frog;
Sitebulb;
OnCrawl;
DeepCrawl.

Не так важно, какому именно производителю вы отдадите своё предпочтение. Главное, чтобы инструмент:

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

Google Search Console

Это само собой разумеется, но на всякий случай стоит отметить. Вам будет необходим доступ к Google Search Console, чтобы провести технический SEO-аудит. Для обнаружения некоторых проблем потребуются исторические данные по проекту.

Проблема №1: петля канонического редиректа

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

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

Почему это имеет значение

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

Таким образом, Google начнёт чаще просматривать веб-страницу с 301-м перенаправлением, которая посылает Googlebot сигнал о петле редиректа.

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

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

Как обнаружить петли канонического редиректа

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

Запустите ваш любимый софт для SEO-аудита. Обязательно просканируйте карту сайта, помимо стандартного сканирования краулером.
Перейдите к отчёту о canonical и экспортируйте все канонические URL. Только не те, которые обошёл робот, а те, что указаны в теге canonical.
Запустите новую проверку по этим адресам и посмотрите на коды ответов. Все URL должны возвращать код ответа со статусом 200.

Проблема №2: страницы, взломанные хакерами

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

Касательно именно SEO, сейчас распространены следующие виды взлома:

Манипулирование поиском сайта. Это происходит в тех случаях, когда страницы результатов поиска по сайту открыты для индексации. Злоумышленник ставит кучу обратных ссылок на такие страницы с нерелевантными запросами. Такое часто встречается в гемблинге и фарме.
Манипулирование 301 редиректом. Это происходит, когда кто-то получает доступ к сайту, создаёт на нём страницы по определённой теме, и добивается их индексации. Затем с таких страниц делается 301 редирект на сторонний сайт.
Захват сайта. Это самая простая атака. Хакер производит манипуляции с кодом сайта и делает его непригодным для использования. Ну или, по крайней мере, портит индексацию.

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

Почему это имеет значение

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

Как обнаружить взломанные страницы

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

Увы, большинство из подобных инструментов ищут только вредоносное ПО (malware). А некоторые хакеры умеют заметать следы. Однако всё равно есть способы узнать, не был ли сайт взломан в прошлом.

Используйте Google Search Console

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

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

Отчёт об эффективности контента в результатах поиска

Проверьте отчёт о покрытии. Ищите серьёзные изменения в каждом подотчёте.

Проверьте аккаунты пользователей веб-сайта

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

Используйте специальные инструменты для онлайн-сканирования

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

Как вариант, можно использовать инструмент «Have I Been Pwned?». Он подскажет вам, были ли ваши адреса электронной почты скомпрометированы утечкой данных.

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

Проблема №3: определение JavaScript-ссылок

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

Исторически сложилось так, что SEO-специалисты искали JS-ссылки, вручную просматривая страницы сайтов (или ориентировались на глубину вложенности в отчётах). Сейчас же уже можно больше полагаться на софт в этом вопросе.

Почему это имеет значение

Googlebot не краулит JavaScript-ссылки на веб-страницах.

Как находить JavaScript-ссылки на больших сайтах

Большинство SEO-инструментов не могут обнаружить JS-ссылки, по умолчанию. Но в софт можно внести небольшие изменения, которые решат данную проблему. Для этого потребуются пользовательские инструменты поиска.

К сожалению, браузеры не отображают исходный код в DOM, поэтому мы с вами не можем искать «onclick» или что-то в этом роде. Но, в качестве альтернативы, есть несколько распространённых типов кода. Только не забудьте вручную проверить, что это действительно JS-ссылки.

<button>. Большинство разработчиков используют тег кнопки для запуска событий JS. Не думайте, что все кнопки являются JS-ссылками, но их идентификация может помочь уменьшить проблему.
data-source. «Источник данных». Подтягивание файла для использования кода при выполнении действия (вроде правильно написал, поправьте меня в комментариях, если что). Часто используется в JS-ссылках.
.js. Подобно атрибуту data-source, некоторые HTML-теги тянут внешний файл JavaScript, чтобы найти указания для выполнения действия.

Проблема №4: контент, скрытый за JavaScript

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

Одной из лучших практик является сочетание хорошего контента с хорошим UX. Но SEO при этом страдать не должно. И для таких проблем есть обходной путь.

Почему это имеет значение

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

У Яндекса недавно появился в Вебмастере новый инструмент на эту тему: «Рендеринг страниц JavaScript». По идее, он позволяет роботу Яндекса индексировать сайты, контент которых формируется через JavaScript. Но у меня пока нет практических данных (если у вас есть – напишите в комментариях).

Как найти контент, скрытый за JavaScript

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

Чтобы выявить скрытый контент, достаточно проверить DOM на веб-странице.

Для поиска скрытого контента:

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

Инструмент не должен заменять специалиста

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

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