Технический аудит для разработчика

Технический SEO-аудит — это проверка инфраструктуры и кода сайта на корректность взаимодействия с поисковыми роботами. Это базовая часть подготовки к продвижению сайтов: без чистого технического состояния остальные SEO-работы не дают эффекта. В отличие от контентного или ссылочного, технический блок зависит от разработчика и DevOps-инженера: настройки сервера, файлы robots.txt и sitemap.xml, шаблоны CMS, обработчики ошибок, HTTP-заголовки. Чек-лист технического аудита разбирает проверки по группам, с конкретными командами, инструментами и критериями оценки. Это аудит для разработчика, тимлида и DevOps-инженера, которые внедряют SEO-правки на стороне кода и сервера.

Зачем технический аудит и кто его проводит

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

Технический аудит проводит разработчик, технический SEO-специалист или DevOps-инженер — в зависимости от размера команды и сложности проекта. SEO-специалист общего профиля может выявить проблемы, но их исправление почти всегда требует доступа к коду или серверной части. Поэтому формат «SEO-специалист готовит ТЗ для разработчика» — рабочий, но менее эффективный, чем когда разработчик сам понимает SEO-требования и закладывает их в код на этапе разработки.

Технический аудит обычно занимает 1–3 рабочих дня для среднего сайта и 1–2 недели для крупного интернет-магазина или портала. Часть проверок автоматизируется через краулеры (Screaming Frog, Sitebulb, JetOctopus), часть требует ручной проверки с просмотром кода, заголовков и серверных логов. Качество аудита зависит не только от полноты чек-листа, но и от глубины разбора каждой проблемы: формальная запись «есть 4xx-ошибки» без анализа их источника и приоритета бесполезна.

Инструментарий разработчика

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

В большинстве проектов хватает связки Google Search Console + Яндекс Вебмастер + Screaming Frog + PageSpeed Insights + Lighthouse. Sitebulb, JetOctopus и WebPageTest добавляются для углублённой работы по конкретным направлениям.

Индексация и управление обходом

Базовая группа проверок, которая определяет, видит ли поисковик сайт вообще и какие именно страницы индексирует.

• robots.txt существует. Файл доступен по domain.by/robots.txt, возвращает HTTP-статус 200, не закрыт от поисковых роботов.
• robots.txt не блокирует ключевые разделы. Проверить директивы Disallow на главную, категории, посадочные страницы. Типичная ошибка после редизайна — оставленный с тестового стенда Disallow: /, полностью закрывающий сайт.
• Sitemap указан в robots.txt. Директива Sitemap: https://domain.by/sitemap.xml присутствует. Если sitemap-индексов несколько, перечислены все.
• sitemap.xml корректен. XML-карта валидна по схеме, содержит только индексируемые URL (без 404, без noindex, без Disallow), даты обновления актуальные, приоритеты выставлены осознанно.
• Размер sitemap в норме. Один файл — не более 50 МБ и не более 50 000 URL. Для больших сайтов — sitemap-индекс с разбивкой по разделам.
• Мета-тег robots на ключевых страницах. Тег <meta name="robots" content="index, follow"> присутствует или отсутствует (по умолчанию открыто к индексации). На странице нет случайного noindex.
• X-Robots-Tag в HTTP-заголовках. Проверить через curl: curl -I https://domain.by/page. Заголовок X-Robots-Tag не должен содержать noindex или nofollow на индексируемых страницах.
• Нет конфликтов между Disallow и noindex. Страница, закрытая в robots.txt, не имеет мета-noindex (поисковик не сможет прочитать тег, так как страница недоступна для обхода).
• Покрытие индексации. Отчёт «Покрытие» в Google Search Console и «Страницы в поиске» в Яндекс Вебмастере: количество страниц в индексе совпадает с ожидаемым.
• Заявки на переобход. После значимых правок отправлять URL на переобход через «Проверка URL» в Search Console и «Переобход страниц» в Яндекс Вебмастере.

Редиректы и HTTP-статусы

Корректные HTTP-статусы — основа правильного восприятия сайта поисковиками. Каждая страница возвращает осмысленный статус, без хаотичных 200 на несуществующих URL или 301 на действующие.

• 200 OK на основных страницах. Главная, категории, посадочные, контентные страницы возвращают 200. Проверка через curl или Screaming Frog.
• 404 на несуществующих URL. Удалённые страницы возвращают честный 404, не 200 с пустым контентом и не редирект на главную. Кастомная 404-страница с навигацией и поиском.
• 410 для окончательно удалённого контента. Если страница удалена навсегда, корректно возвращать 410 Gone — это ускоряет удаление из индекса.
• 301 для постоянных редиректов. Все перенаправления старых URL на новые после переезда — через 301, не 302.
• 302 только для временных. 302 — для временных перенаправлений (тестовая страница, А/Б-тест). Постоянное использование 302 вместо 301 теряет ссылочный вес.
• Цепочки редиректов. Не более 1–2 шагов в цепочке. Длинные цепочки замедляют переобход и тратят crawl budget. Отчёт Screaming Frog по Redirect Chains.
• Нет петель. Редиректы не образуют циклов. Браузер показывает «слишком много перенаправлений», поисковик отказывается от обхода.
• HTTPS-редирект. http://domain.by → https://domain.by через 301. Без промежуточного шага.
• Каноническая форма домена. Выбор между www и без www — одна форма основная, вторая редиректит через 301.
• Trailing slash. URL с конечным слешем и без — выбрана одна каноническая форма, вторая редиректит на основную.
• 5xx ошибки отсутствуют. Серверных ошибок в обычной работе сайта не должно быть. Логи сервера за последние 30 дней проверены — массовых 500, 502, 503, 504 нет.

Canonical и дубли

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

• Тег canonical на каждой странице. <link rel="canonical" href="https://domain.by/page"> в секции <head>.
• Canonical ведёт на правильный URL. Не на главную (типичная ошибка после редизайна), не на устаревший URL.
• Self-referencing canonical. Большинство страниц должны иметь canonical, ведущий на собственный URL — это явное указание поисковику, что страница каноническая.
• Нет противоречий с robots. Canonical не ведёт на страницу, закрытую в robots.txt или мета-noindex.
• Параметры URL. Страницы с UTM-метками, параметрами фильтров, сортировкой имеют canonical на основной URL без параметров.
• Регистр URL. /Page и /page — для поисковика разные URL. Один вариант канонический, другой редиректит на основной.
• Слеши. /page и /page/ — тоже разные URL. Выбрана одна форма, вторая редиректит.
• Дубли мета-данных. Через Screaming Frog отчёт по дублирующимся title и meta description: каждая страница уникальна, без массовых повторов.
• Дубли H1. Один тег H1 на страницу, не несколько. И уникальные H1 на разных URL.
• Дубли по содержанию. Сходные страницы с разным URL (например, один товар в нескольких категориях) либо консолидируются через canonical, либо различаются по контенту достаточно для самостоятельной индексации.

HTTPS и безопасность

HTTPS — базовое требование современного веба и явный фактор ранжирования для Google. Также часть SEO-задач прямо завязана на безопасность: взломанный сайт быстро теряет позиции, а в худшем случае — выпадает из индекса.

• SSL-сертификат действителен. Срок действия не истёк, цепочка сертификатов корректна. Проверка через SSL Labs или браузер.
• Автоматическое продление. Сертификат продлевается автоматически. Истекший сертификат на сайте — критический инцидент.
• Mixed content отсутствует. На HTTPS-страницах нет ссылок и ресурсов по HTTP (картинки, скрипты, шрифты). Браузер блокирует или предупреждает.
• HSTS-заголовок. HSTS (HTTP Strict Transport Security — строгий механизм безопасной передачи) задаётся через заголовок Strict-Transport-Security в HTTP-ответах сервера. Браузер принудительно использует HTTPS, без возможности downgrade.
• Все HTTP-URL редиректят на HTTPS. 301-редирект, без отдачи контента по http.
• Конфигурация TLS. Версия TLS 1.2 или 1.3 (без устаревших TLS 1.0/1.1), стойкие шифры. Проверка через SSL Labs — оценка не ниже B, оптимально A или A+.
• CSP (Content Security Policy). Заголовок CSP настроен для защиты от XSS (Cross-Site Scripting — межсайтовый скриптинг) и инъекций сторонних скриптов.
• X-Frame-Options или CSP frame-ancestors. Защита от clickjacking — встраивания сайта в iframe на чужом домене.
• Безопасность административной части. Двухфакторная аутентификация (2FA) для админов CMS, ограничение доступа по IP при возможности.
• Регулярные обновления CMS и плагинов. Все компоненты в актуальных версиях с патчами безопасности.

Core Web Vitals и скорость

Core Web Vitals — набор метрик, прямо влияющих на ранжирование в Google и пользовательский опыт в обеих поисковых системах. Замер делается через PageSpeed Insights, Lighthouse, WebPageTest и Chrome User Experience Report (CrUX) для реальных данных пользователей.

• LCP (Largest Contentful Paint, наибольшее содержательное отображение). Целевое значение ≤ 2.5 секунды для 75% пользователей. Чаще всего портит LCP большая нерастянутая картинка героя или поздно загружающийся шрифт.
• CLS (Cumulative Layout Shift, накопленный сдвиг разметки). Целевое ≤ 0.1. Источники проблем: картинки без указания размеров, поздно подгружаемая реклама, шрифты с FOIT (Flash of Invisible Text — вспышка невидимого текста) или FOUT (Flash of Unstyled Text — вспышка нестилизованного текста).
• INP (Interaction to Next Paint, отклик на взаимодействие). Целевое ≤ 200 мс. Заменила FID (First Input Delay — задержка первого ввода) в марте 2024 года. Тяжёлые JavaScript-обработчики, блокирующие main thread, — основная причина высокого INP.
• TTFB (Time to First Byte, время до первого байта). Целевое ≤ 600 мс. Высокий TTFB указывает на медленный backend, проблемы с базой данных или хостинг с большой задержкой.
• Оптимизация изображений. Современные форматы (WebP, AVIF) с откатом на JPEG для старых браузеров. Размеры изображений соответствуют отображаемым на странице.
• Lazy-loading. Изображения вне видимой области загружаются отложенно через атрибут loading="lazy".
• Минификация и сжатие. HTML, CSS, JavaScript минифицированы. Сервер отдаёт контент в сжатом виде (gzip или Brotli).
• Кеширование. Статические ресурсы (CSS, JS, шрифты, изображения) с долгими заголовками Cache-Control. Версионирование через хеши в именах файлов.
• CDN. Для проектов с международной аудиторией или большим объёмом статики — Content Delivery Network ускоряет отдачу с географически ближайшего сервера.
• Шрифты. Подключение через font-display: swap для избежания FOIT, локальное хранение или приоритетная подгрузка через preload.

Мобильная версия и адаптивность

Mobile-first индексация запущена Google в марте 2018 года и полностью развёрнута к октябрю 2023 года. Для большинства сайтов сегодня основная версия — мобильная: именно она индексируется и ранжируется в первую очередь.

• Адаптивный дизайн. Сайт корректно отображается на устройствах с шириной от 320 px до десктоп-разрешений. Без горизонтальной прокрутки.
• Viewport meta. <meta name="viewport" content="width=device-width, initial-scale=1"> в head каждой страницы.
• Текст без зума. Размер шрифта в основном тексте — минимум 16 px на мобильных. Без обязательного зума для чтения.
• Tap targets. Кликабельные элементы (кнопки, ссылки) — минимум 48×48 px, с отступами друг от друга. Иначе пользователь часто промахивается.
• Контент-парность. Мобильная и десктоп-версия отдают одинаковый основной контент. Скрытие текстов на мобильных через display:none снижает релевантность.
• Отдельный мобильный поддомен. Если используется m.domain.by, настроены связки rel=”alternate” и rel=”canonical” между версиями, корректные редиректы.
• AMP (Accelerated Mobile Pages). Если используются AMP-страницы — связки rel=”amphtml” и canonical настроены, AMP проходит валидацию.
• Тач-жесты. Свайп, пинч-зум работают без блокировок CSS. Карусели, слайдеры адаптированы под сенсорный ввод.
• Скорость на мобильных. PageSpeed Insights отдельно показывает мобильные метрики — целевые те же, что для десктопа, но достигаются сложнее из-за более слабого железа и сетей.
• Тестирование на реальных устройствах. Эмулятор браузера показывает базовую картину, но финальная проверка — на физических смартфонах разных диагоналей и операционных систем.

Микроразметка Schema.org

Микроразметка помогает поисковикам корректно интерпретировать содержимое страницы и формировать расширенные сниппеты в выдаче.

• Organization или LocalBusiness. На главной странице — разметка организации с названием, логотипом, контактами, социальными сетями. Для локального бизнеса — LocalBusiness с адресом, часами работы, телефоном.
• BreadcrumbList. Хлебные крошки размечены через Schema.org BreadcrumbList. Позволяет поисковику показывать структуру навигации в сниппете.
• Article или NewsArticle. На контентных страницах блога — разметка статьи с автором, датой публикации, изображением, описанием.
• Product. На карточках товара — Product с ценой, наличием, рейтингом, отзывами.
• FAQPage. Блоки вопросов и ответов размечены как FAQPage — формирует расширенный сниппет с раскрывающимися ответами.
• HowTo. Пошаговые инструкции — разметка HowTo, показывается в выдаче с пронумерованными шагами.
• Review и AggregateRating. Отзывы и сводный рейтинг — для товаров и услуг.
• Event. События — конференции, концерты, акции — размечены как Event с датой, местом, описанием.
• Формат JSON-LD. Рекомендованный формат микроразметки от Google — JSON-LD в теге <script type="application/ld+json">. Микроформаты и RDFa также поддерживаются, но JSON-LD проще в обслуживании.
• Валидация. Каждая разметка прогоняется через Schema Markup Validator и Rich Results Test от Google. Без ошибок и предупреждений.

hreflang и многоязычные сайты

Для сайтов с языковыми или региональными версиями hreflang — критическая настройка. Ошибки в hreflang приводят к показу русскоязычным пользователям английской версии или наоборот.

• Атрибут hreflang на каждой странице. В head или в HTTP-заголовках или в sitemap — указано соответствие между языковыми версиями страницы.
• Двусторонние связи. Если страница A ссылается на B через hreflang, страница B должна ссылаться на A. Иначе поисковик игнорирует разметку.
• Код языка и региона. Корректные коды по стандарту ISO 639-1 для языков (ru, en, be) и ISO 3166-1 alpha-2 для регионов (BY, RU, US). Например, hreflang="ru-BY".
• x-default. Указана версия по умолчанию для пользователей, чей язык/регион не покрыт другими версиями: hreflang="x-default".
• Без петель. Hreflang не ведёт на страницу с canonical на другую — алгоритм не может однозначно определить, какая версия каноническая.
• Согласованность с canonical. Каждая версия — self-referencing canonical, при этом связаны hreflang с другими версиями.
• Валидация в Google Search Console. Отчёт «Международная ориентация» (если доступен) показывает ошибки в hreflang.
• Соответствие контента языку. На странице с hreflang=”be-BY” — белорусский контент, не машинный перевод с русского.
• Реализация в sitemap. Для крупных сайтов hreflang удобнее реализовать через расширения sitemap, чем дублировать на каждой странице.
• Региональные домены. Если используются разные домены для разных стран (.by, .ru, .ua), hreflang корректно связывает их между собой.

JavaScript-рендеринг и динамический контент

Современные сайты часто построены на JavaScript-фреймворках (React, Vue, Angular). Контент, генерируемый JS, должен быть доступен поисковым роботам.

• Контент в HTML до выполнения JS. Идеальный вариант — SSR (Server-Side Rendering) или статическая генерация, когда основной контент отдаётся в исходном HTML, без необходимости выполнения скриптов.
• Pre-rendering или dynamic rendering. Альтернатива SSR — pre-rendering: для ботов сервер отдаёт готовый HTML, для пользователей — обычное SPA (Single Page Application — одностраничное приложение). Сложнее в поддержке, но работает.
• «Просмотр как Googlebot». Инструмент «Проверка URL» в Google Search Console показывает, что видит робот после рендеринга. Если основной контент отсутствует — проблема.
• «Проверка URL» в Яндекс Вебмастере. Аналогичная проверка для Яндекс Бота.
• Lazy-loaded контент. Контент, подгружаемый по скроллу или клику, может быть невидим роботу. Критичные блоки должны быть в исходном HTML.
• Бесконечный скролл. Если каталог использует бесконечный скролл, дополнительно реализована пагинация с уникальными URL — иначе боты не доходят до глубоких страниц.
• Шрифты и иконки. Шрифт-иконки и шрифты подгружаются без блокировки рендеринга основного контента.
• Ошибки в консоли. JS-ошибки в DevTools браузера могут ломать рендеринг для робота. Чистая консоль — норма.
• Размер JS-бандла. Большие бандлы (более 300–500 КБ после gzip) замедляют рендеринг. Code splitting, tree shaking, lazy import.
• Третьи скрипты. Аналитика, чаты, виджеты — асинхронная загрузка, чтобы не блокировать основной рендеринг.

Crawl budget и логи сервера

Crawl budget — количество URL, которое поисковый бот готов обойти на сайте за определённый период. На небольших сайтах вопрос не критичен, на крупных — определяет, какие страницы попадают в индекс быстро, а какие — с задержкой или вообще не попадают.

• Логи сервера за 30 дней. Анализ access-логов веб-сервера (server logs): какие URL посещает Googlebot и Яндекс Бот, как часто, какие статусы получает.
• Распределение обходов. Боты в основном посещают важные страницы. Если 50%+ обходов уходит на технические URL (страницы фильтров, пагинация, параметры) — crawl budget тратится впустую.
• Закрытие технических URL. Через robots.txt закрываются параметры сортировок, страницы корзины и личного кабинета, технические admin-разделы.
• Параметры в URL. В Google Search Console раньше был раздел Parameters; сейчас управление через canonical и robots.txt. Параметры фильтров, не дающие уникального контента, исключаются из обхода.
• Пагинация без бесконечного множества страниц. На сайтах с фильтрами может генерироваться огромное количество комбинаций пагинации. Часть закрывается robots.txt, часть — через canonical на первую страницу.
• Скорость отдачи страниц. Чем быстрее сервер отвечает, тем больше URL бот успевает обойти за сессию. Снижение TTFB прямо влияет на crawl budget.
• 404 и 410 в логах. Боты тратят бюджет на повторные обращения к 404 страницам. Серверные 5xx тоже снижают эффективный бюджет — бот откладывает повторный визит.
• Карта sitemap как приоритет. Sitemap указывает на важные страницы — бот в первую очередь обходит их.
• Внутренняя перелинковка. Страницы, на которые ведут много внутренних ссылок, бот посещает чаще. Сиротские страницы (без внутренних ссылок) могут не индексироваться годами.
• Sitemap для свежего контента. Новые страницы публикуются с обновлением sitemap и заявкой на переобход — это ускоряет первый визит бота.

Типичные ошибки и как их избежать

Особенности для белорусского бизнеса

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

Гео-привязка в Яндекс Вебмастере. В разделе «Региональность» проверяется правильность установленного региона: Беларусь целиком или конкретный город. Неверно выставленный регион снижает позиции по локальным запросам.

Двуязычная разметка. Для сайтов на русском и белорусском языках hreflang устанавливается как ru-BY и be-BY. Машинный перевод с русского на белорусский легко детектируется поисковиками и пользователями — для серьёзной двуязычной поддержки нужен носитель языка для адаптации текстов.

Доменная зона .by. Для бизнеса с белорусской аудиторией основной домен в зоне .by даёт лучшие сигналы геопринадлежности. Техническим администратором зоны .by является hoster.by, регистрация и продление доменов идут через аккредитованных регистраторов. БелГИЭ (Белорусская государственная инспекция по электросвязи) выполняет роль государственного регулятора электросвязи и принимает регистрации сайтов как сетевых изданий и интернет-ресурсов согласно требованиям законодательства. Сроки регистрации и продления домена отслеживаются заранее — задержки с оплатой могут привести к освобождению домена и потере SEO-истории.

Хостинг и TTFB. Для белорусской аудитории хостинг физически в Беларуси или соседних странах даёт меньший TTFB, чем хостинг в США или Юго-Восточной Азии. На европейских хостингах с CDN ситуация выравнивается.

HTTPS и государственные ресурсы. Для отдельных категорий сайтов (государственные сервисы, банки) могут применяться дополнительные требования к шифрованию и сертификатам — это уточняется в технической документации соответствующих регуляторов.

Карточки в Яндекс Бизнесе и 2ГИС. Технические проверки гео-привязки на сайте дополняются ручной проверкой соответствия данных в карточках Яндекс Бизнеса, Google Business Profile и 2ГИС. Расхождения снижают локальное ранжирование.

Часто задаваемые вопросы

Должен ли разработчик разбираться в SEO для проведения технического аудита?

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

Как распределить рабочие дни аудита по техническим блокам?

Для среднего корпоративного сайта (до 1000 страниц) на день 1 закрываются три самых критичных блока: индексация, редиректы и HTTP-статусы, canonical и дубли. Это базовая «гигиена», которая обычно даёт основную часть критических находок. День 2 — Core Web Vitals, мобильная версия, HTTPS и безопасность. День 3 — микроразметка, hreflang (если сайт многоязычный), JavaScript-рендеринг и crawl budget с разбором логов сервера. На крупных интернет-магазинах и порталах с тысячами URL первая неделя уходит на полный краулинг и анализ выгрузок, вторая — на ручную проверку конфигурации, серверных заголовков и микроразметки по образцам. Если деплои происходят регулярно, имеет смысл закрепить ответственного за технический аудит и проводить срезы после каждого крупного релиза вместо одного длинного аудита раз в полгода.

Какой инструмент для краулинга выбрать — Screaming Frog или Sitebulb?

Screaming Frog — классика и стандарт, подходит для большинства проектов. Бесплатная версия до 500 URL хороша для небольших сайтов. Платная — без ограничений, с поддержкой JS-рендеринга и интеграцией с GSC, Ahrefs. Sitebulb — глубже в интерпретации находок, генерирует понятные отчёты с приоритизацией, подходит для аудита с передачей не-разработчику. Часто крупные команды используют оба сервиса параллельно — Screaming Frog для скоростного краулинга, Sitebulb для формирования отчётов.

Можно ли провести технический аудит без доступа к коду?

Большая часть проверок (robots.txt, sitemap, HTTP-статусы, мета-теги, микроразметка, Core Web Vitals) делается без доступа к коду — через публичные URL и инструменты. Но без доступа к коду невозможно проверить настройки шаблонов CMS, серверные заголовки, конфигурацию веб-сервера, обработку параметров URL на бэкенде. Полный аудит в любом случае требует доступа разработчика или скриншотов конфигурации.

Как часто нужно повторять технический аудит?

Для стабильного сайта без активной разработки — раз в 6–12 месяцев. Для проекта в активной фазе развития с регулярными релизами — раз в 1–3 месяца, с акцентом на проверку, не появились ли регрессии после последних деплоев. Внеплановые аудиты обязательны после крупных изменений: редизайн, переезд на новый домен, смена CMS, изменение URL-структуры. Часть проверок (Core Web Vitals, индексация, ошибки в Search Console) полезно автоматизировать с уведомлениями при отклонениях.

Что важнее — Core Web Vitals или контент?

Это разные категории факторов и сравнивать напрямую не имеет смысла. Core Web Vitals — это «гигиена», порог входа: с провальными метриками сайт не получает преимущества от хорошего контента. С метриками в зелёной зоне они уже не дают дополнительного буста — дальше работает контент и ссылочный профиль. Технический аудит закрывает базовые проблемы, после чего фокус смещается на контент.

Стоит ли использовать AMP сегодня?

Значение AMP сегодня заметно снизилось: Google убрал требование AMP для попадания в «Top stories» в выдаче, и многие издания отказались от формата. Использование AMP остаётся осмысленным в нишах, где скорость на мобильных критична (новости, ленты публикаций), и где аудитория преимущественно мобильная. Для большинства корпоративных сайтов, интернет-магазинов, B2B-сервисов AMP избыточен — современный адаптивный дизайн с оптимизацией Core Web Vitals закрывает те же задачи без дополнительного формата.

Как обнаружить, что сайт взломан с точки зрения SEO?

Несколько типичных признаков: внезапное появление чужих страниц в индексе через site:domain.by, ухудшение позиций без очевидной причины, появление в выдаче сниппетов с чужим содержимым, предупреждения в Google Search Console и Яндекс Вебмастере в разделах безопасности, неожиданные ссылки на сайте (часто скрытые от пользователей, но видимые ботам), всплески нерелевантного трафика. При подозрении — сравнение текущих файлов CMS с резервной копией, проверка через сервисы безопасности (Sucuri, VirusTotal), смена всех паролей с административным доступом.