Технический аудит сайта: 20 пунктов перед началом SEO
Контентная работа без технического аудита — деньги на ветер: Google не ранжирует то, что не может корректно проиндексировать. Двадцать пунктов ниже — минимум, который стоит проверить до первой правки текста на сайте.
Индексация и доступность (пункты 1-5)
1. Проверьте robots.txt на случайные Disallow: /, оставшиеся после разработки — частая причина, по которой новый сайт месяцами не индексируется. 2. Сверьте sitemap.xml с реальной структурой сайта: устаревшие URL в карте, ведущие на 404, путают краулер. 3. В Search Console откройте отчёт «Индексирование страниц» и разберите каждую причину исключения, а не только общее число проиндексированных.
4. Проверьте канонические ссылки на каждом типе шаблона: домашняя, категория, карточка товара, статья блога — canonical должен указывать на саму страницу или на осознанно выбранную версию, а не на случайный URL из-за бага CMS. 5. Убедитесь, что HTTPS настроен без смешанного контента (mixed content) — незашифрованные картинки или скрипты на https-странице подрывают доверие браузера и части ранжирующих сигналов.
Архитектура и дубли (пункты 6-10)
6. Проверьте, не создаёт ли сайт дублей через www/без www или http/https одновременно доступные без редиректа — это классический источник расщепления ссылочного веса. 7. Найдите дубли title и meta description через выгрузку Screaming Frog: страницы с одинаковым title почти всегда сигнализируют о структурной проблеме, а не просто забытой правке.
8. Проверьте глубину вложенности ключевых страниц — свыше четырёх кликов от главной резко снижает частоту обхода. 9. Посмотрите на структуру внутренней перелинковки: страницы-сироты без единой входящей внутренней ссылки Google находит только через sitemap и обходит их реже. 10. Проверьте пагинацию: ссылки на следующие страницы должны быть кликабельными <a href>, а не только JS-обработчиком без изменения URL.
Скорость и Core Web Vitals (пункты 11-14)
11. Проверьте LCP (Largest Contentful Paint) в PageSpeed Insights для мобильной версии — целевой порог 2,5 секунды, выше 4 секунд считается «плохо» и напрямую влияет на ранжирование как часть page experience. 12. Проверьте CLS (Cumulative Layout Shift): смещение вёрстки из-за картинок без заданных width/height или рекламных блоков, всплывающих после загрузки.
13. Проверьте INP (Interaction to Next Paint), который заменил FID как метрика отзывчивости с марта 2024 года — тяжёлые скрипты аналитики и чат-виджеты часто держат главный поток и увеличивают задержку отклика на тап. 14. Проверьте вес и формат изображений: JPEG и PNG на карточках товара вместо WebP или AVIF на сайте с тысячей SKU — самая частая причина низкого LCP у интернет-магазинов.
Мобильная версия и разметка (пункты 15-17)
15. Проверьте отчёт «Удобство для мобильных устройств» в Search Console (или актуальный аналог в разделе Core Web Vitals) — текст мельче 12px и элементы интерфейса ближе 8px друг к другу считаются ошибкой юзабилити. 16. Проверьте структурированные данные через Rich Results Test: для интернет-магазина — Product и BreadcrumbList, для локального бизнеса — LocalBusiness, для блога — Article.
17. Проверьте hreflang для мультиязычных сайтов: для трёх версий ru/uz/en каждая языковая версия должна ссылаться на себя и на две остальные, включая x-default. Односторонние или неполные hreflang-цепочки Google в лучшем случае игнорирует, в худшем — путает языковые версии в выдаче.
Контентные технические сигналы (пункты 18-20)
18. Проверьте уникальность title и description по всему сайту — совпадение на 5% страниц ещё терпимо, на 30% уже структурная проблема шаблона. 19. Проверьте иерархию заголовков H1-H2-H3: единственный H1 на странице, логичная вложенность подзаголовков без пропуска уровней ради визуального стиля.
20. Проверьте статус страниц об ошибках: кастомная 404-страница с навигацией и поиском вместо шаблона хостинга, и правильные коды ответа — 410 для окончательно удалённых страниц вместо мягкого 200 с текстом «страница не найдена», который вводит краулер в заблуждение.
Как использовать чек-лист на практике
Проходите пункты не по порядку важности, а по трудозатратам: индексация и дубли (1-10) чинятся быстро и дают эффект в течение недель, Core Web Vitals (11-14) требуют работы разработчика и месяца на стабилизацию метрик, мультиязычность и разметка (15-20) — разовая настройка с долгим эффектом.
Фиксируйте baseline перед началом работ: скриншот отчётов Search Console, экспорт краулинга Screaming Frog, показатели PageSpeed Insights. Без зафиксированной точки отсчёта через три месяца невозможно доказать клиенту или себе, что технический аудит вообще что-то изменил.