Технический SEO-аудит не начинается с графиков видимости и сложных отчётов. Сначала проверяют вещи, которые можно увидеть обычным браузером: открываются ли страницы, не ломается ли мобильная версия, понятен ли адрес документа, не закрыт ли сайт от поисковых роботов и не теряются ли важные разделы в навигации. Базовую проверку реально провести самостоятельно за один-два часа, если идти не по ощущениям, а по конкретному сценарию.
Главный вопрос здесь простой: какие ошибки можно найти без платных платформ и профессиональных краулеров? Ответ — почти все очевидные технические проблемы, которые мешают индексации и ухудшают пользовательский опыт. Вручную обнаруживаются битые ссылки, неправильные редиректы, дубли страниц, отсутствие важных метатегов, ошибки в robots.txt и sitemap.xml, незащищённое соединение, проблемы с адаптивностью и слишком медленная загрузка. Если после первичной проверки требуется оценить структуру, индексацию и ссылочные ограничения глубже, можно обратиться к специалистам https://seo2you.ru/services/audity/kompleksnyi-audit/.
При этом ручной аудит не заменяет полноценный анализ крупного интернет-магазина или портала. У сайта на 20 страниц достаточно открыть документы по очереди. У проекта на 50 000 URL неизбежно появятся выборка, автоматический сбор данных и проверка логов сервера. Но даже в таком случае самостоятельная диагностика полезна: она помогает понять масштаб проблемы и не тратить время специалиста на неисправности, которые устраняются за несколько минут.
Ниже — самостоятельный алгоритм, с которого разумно начать до привлечения подрядчика.
1. Проверка доступности сайта и основных URL
Откройте главную страницу в обычном браузере, затем проверьте несколько типовых адресов: страницу категории, карточку товара или услуги, статью, страницу контактов. Важно смотреть не только на результат в браузере, но и на адресную строку. Если URL неожиданно меняется, появляется цепочка переадресаций или страница загружается по нескольким вариантам адреса, это уже повод для проверки.
Код ответа 200 означает, что документ доступен. Код 301 сообщает о постоянном перенаправлении, 302 — о временном. Ошибка 404 уместна для действительно удалённой страницы, но плохо, когда такой ответ получают важные разделы, ссылки из меню или страницы, на которые ведут внешние упоминания. Ошибка 500 указывает на проблему на стороне сервера и требует более срочной реакции.
Проверьте варианты с протоколами http:// и https://, а также с www и без него. Рабочей должна оставаться одна основная версия. Остальные варианты должны вести на неё через один постоянный редирект 301, а не проходить цепочку вроде «http с www → http без www → https без www». Каждое дополнительное перенаправление увеличивает время загрузки и усложняет обработку URL.
Критически важно: не удаляйте редиректы вслепую. Старый адрес может иметь внешние ссылки, историю и переходы из закладок. Сначала определите, куда он должен вести, и только потом меняйте правила сервера.
2. Что видно в исходном коде страницы
Откройте исходный код сочетанием клавиш Ctrl+U или через контекстное меню браузера. Поиск по странице поможет быстро найти теги <title>, <meta name="description">, <h1>, canonical и директиву noindex.
У каждой важной страницы должен быть осмысленный заголовок title. Он не обязан повторять заголовок на странице, но должен объяснять поисковику и пользователю, что находится в документе. Пустой title, одинаковые titles у десятков страниц и набор ключевых слов через запятую — признаки небрежной настройки. Description напрямую не гарантирует хорошую позицию, однако влияет на то, как страница выглядит в выдаче и насколько убедительно звучит её сниппет.
Отдельно проверьте заголовки. В большинстве случаев странице нужен один логичный h1, отражающий её тему. Несколько h1 не всегда являются технической катастрофой, особенно в сложных шаблонах HTML5, но хаотичная иерархия вроде h3 перед h2 ухудшает структуру документа. Заголовки должны делить материал на смысловые блоки, а не служить способом визуально увеличить шрифт.
Тег canonical должен указывать на предпочтительную версию страницы. Ошибка возникает, когда все документы сайта канонизируются на главную или когда canonical ведёт на URL с ошибкой, редиректом либо директивой noindex. В результате поисковая система получает противоречивые сигналы.
3. Robots.txt и sitemap.xml: две минуты на проверку
Добавьте к домену адрес /robots.txt. Файл должен открываться без ошибки сервера и содержать понятные правила. Для базовой проверки найдите директивы Disallow. Если там закрыта вся директория каталога, страницы услуг, статьи или другой коммерчески важный раздел, это потенциальная причина отсутствия URL в поиске.
Запрет в robots.txt не удаляет уже проиндексированную страницу автоматически. Он ограничивает обход, но не всегда исключает адрес из результатов поиска. Поэтому важно не путать robots.txt с метатегом noindex. Первый управляет доступом робота к обходу, второй сообщает о нежелательности индексации документа, если робот может его прочитать.
Затем откройте /sitemap.xml. В карте должны находиться канонические, доступные для индексации URL с кодом 200. Не стоит включать туда страницы поиска по сайту, фильтры с бесконечными комбинациями параметров, дубли, редиректы и документы с noindex. Дата изменения в sitemap должна отражать реальное обновление страницы, а не автоматически меняться каждый день.
4. Мобильная версия и скорость
Сузьте окно браузера или включите режим эмуляции смартфона в DevTools. Проверьте, не появляется ли горизонтальная прокрутка, не перекрывает ли меню текст, читаем ли шрифт без масштабирования и удобно ли нажимать кнопки. Для коммерческого сайта особенно важны форма заказа, телефон, корзина и фильтры: красивый первый экран не компенсирует сломанную ключевую функцию.
Посмотрите, что происходит при первом открытии страницы. Если изображения весят по несколько мегабайт, видео запускается автоматически, а интерфейс долго остаётся пустым, проблема, скорее всего, не в SEO-настройках, а в ресурсах и порядке их загрузки. В DevTools можно открыть вкладку Network и оценить размеры файлов, количество запросов и самые тяжёлые элементы. Изображения обычно стоит отдавать в WebP или AVIF, задавать им реальные размеры и не загружать ниже первого экрана раньше времени.
| Что проверяется | Нормальный результат | Тревожный сигнал |
|---|---|---|
| Мобильная ширина | Контент помещается в экран, нет горизонтального скролла | Текст и кнопки выходят за границы viewport |
| Изображения | Сжатые файлы подходящего размера | Фото загружаются в оригинальном разрешении по 2–5 МБ |
| Ссылки | Ведут на нужные страницы и открываются без ошибок | 404, циклические редиректы, пустые кнопки |
| Безопасность | Везде используется HTTPS без предупреждений браузера | Смешанный контент или сертификат с ошибкой |
Практический ориентир: не оценивайте скорость по ощущениям на мощном компьютере. Проверьте страницу на смартфоне и при медленном соединении. Именно там становятся заметны тяжёлые изображения, блокирующие скрипты и позднее появление основного контента.
5. Внутренняя структура и дубли
Перейдите по сайту так, как это сделал бы новый посетитель: с главной страницы в категорию, из категории в материал или карточку товара, затем к контактам и форме заявки. Важные страницы должны находиться за несколько понятных переходов. Если документ существует, но на него нет ни одной внутренней ссылки, поисковому роботу сложнее обнаружить его, а пользователю — добраться до него.
Проверьте, не создаются ли разные URL для одного и того же содержания. Частые источники дублей — параметры сортировки, метки рекламных кампаний, слеш в конце адреса, заглавные буквы и альтернативные варианты протокола. Например, /catalog и /catalog/ должны либо объединяться редиректом, либо иметь одну согласованную каноническую версию.
Краткая памятка перед исправлениями
- Зафиксировать список важных страниц и их текущие URL.
- Проверить доступность, код ответа и конечный адрес после редиректа.
- Найти в исходном коде title, description, h1, canonical и noindex.
- Открыть robots.txt и sitemap.xml, убедиться, что коммерческие разделы не закрыты.
- Проверить мобильную версию, формы, меню, изображения и HTTPS.
- Сохранить обнаруженные ошибки до внесения изменений, чтобы не потерять исходную картину.
Самостоятельный базовый SEO-аудит — это не попытка заменить полноценное исследование сайта набором случайных кликов. Это быстрая техническая ревизия, которая показывает, доступен ли ресурс поисковику, не конфликтуют ли его настройки и не мешают ли очевидные ошибки пользователю. Начинать стоит с важных URL, кодов ответа, индексационных директив, структуры заголовков, мобильной версии и скорости.
После исправлений проверьте те же страницы повторно. SEO-ошибка часто появляется не из-за одной настройки, а из-за её сочетания с шаблоном, редиректом или CMS. Последовательная проверка помогает увидеть причинно-следственную связь и понять, какие изменения действительно улучшили сайт. Если в процессе обнаружились массовые дубли, нестабильная индексация или сложная архитектура, разумнее передать проект на расширенный аудит, сохранив результаты собственной первичной диагностики.
