Аудит 573 URL за один прогон: лог-анализ + REST-API на WooCommerce

Типичный аудит сайта на 500+ URL занимает у агентства 2–4 недели и стоит как маленькая Tesla. Половина этого срока — не работа, а попытки залогиниться в админку клиента, дождаться доступа к Search Console, выпросить SFTP, и долго общаться по почте с разработчиком, который «уехал в командировку».

Расскажу, как мы делаем то же самое за один день без захода в админку. Кейс — реальный B2B-каталог станков и металлообработки: WordPress 6.9 + WooCommerce + тема Avada, 409 товаров, 148 страниц, 6 поставщиков в режиме маркетплейса. Всего — 573 URL.

Шаг 1: Application Passwords и Rank Math API

Первое, что просим у клиента — Application Password для технического пользователя с правами Editor. Это встроенный механизм WordPress начиная с 5.6, который выдаёт токен для REST API без логина в админку. Один POST-запрос, минута работы клиента.

GET /wp-json/wp/v2/pages?per_page=100&_fields=id,slug,title,status,link
GET /wp-json/wp/v2/posts?per_page=100
GET /wp-json/wc/v3/products?per_page=100
GET /wp-json/rankmath/v1/meta?ids=1,2,3...

Авторизация — Basic Auth с base64 от user:app_password. Никаких ключей в репозитории, никакого SSH. Работает с любого CI-раннера.

Rank Math (один из двух основных SEO-плагинов для WP, рядом с Yoast) с версии 1.0.230 отдаёт 57 REST-эндпоинтов для всего: meta-title, meta-description, robots, schema, canonical, redirects. Это означает что весь SEO-аудит можно собрать без захода в админку и без парсинга HTML.

Шаг 2: что мы ищем

Скрипт аудита (Python, ~600 строк) проходит по списку URL и пишет в SQLite табличку. Для каждого URL — десятки полей. Основные находки, которые мы вытаскиваем за один прогон:

Multi-H1

Классическая ошибка тем-конструкторов: Avada, Elementor, Divi — все умеют генерировать страницы с двумя-тремя H1. На нашем кейсе таких страниц нашлось 26 из 148. Лечится прямым редактированием post_content через REST, без захода в Avada UI (Avada UI ломал бы шаблон при сохранении).

noindex-регрессии

Самое подлое. На нашем кейсе три URL отдавали noindex,nofollow: /logout/, /user/, /account-old/. Первые два — нормально, это служебка. Но /account-old/ у клиента числился как «промо-страница со старым акком» и должен был отдавать index.

Через Rank Math REST правится поле rank_math_robots. Через .htaccess добавляем 302 на главную для UserMembership-роутера, чтобы Googlebot не наткнулся на форму логина.

Alt-теги на товарах

На WooCommerce-каталогах из 400+ товаров alt-теги — это всегда боль. У клиента 8 255 изображений, alt заполнен у 21%. Через wp/v2/media массово апдейтим: каждое изображение получает alt по шаблону {товар} — {категория} — {ракурс}, если ракурс выделяется из EXIF.

Результат после апдейта: 100% покрытие. Скрипт идёт батчами по 50 запросов, ~12 минут на 8 000 изображений.

Sitemap-дубли

Rank Math по умолчанию генерирует attachment-sitemap, который у WooCommerce-каталога раздувается до 5000+ записей с media-attachment URL. Гугл индексирует attachment-страницы как пустые дубли, и они начинают тащить вниз ранжирование товаров.

На кейсе было 12 sitemap-файлов, после чистки — 5 (pages, posts, products, categories, glossary). Attachment-sitemaps отключены через фильтр в functions.php темы.

Шаг 3: лог-анализ

Запросом у клиента access.log за последние 30 дней с Beget (или другого хостинга). На WooCommerce-сайте лог за месяц — обычно 200–800 МБ. Парсим через GoAccess + кастомные скрипты, ищем:

• что реально ходит Googlebot и Yandexbot — какие URL, как часто, с каким response code;
• есть ли 5xx-всплески, на каких URL, в какие часы;
• есть ли «кэш-инвалидация» — Googlebot возвращается на одну и ту же страницу с одинаковым ETag и получает 200, а не 304;
• есть ли 404 от внутренних ссылок (то есть мы сами линкуем на несуществующие URL).

Случай из практики: «месячный кэш-блокер»

На этом проекте мы месяц боролись с одной и той же штукой: правки meta-description через REST сохранялись в БД (мы это видели в SQL), но на лайве через 5 минут возвращались на старое значение. Думали — кеш WP Super Cache. Чистили — не помогло. Думали — Cloudflare. Отключали — не помогло.

Разгадка нашлась через SSH (клиент дал на 6-й неделе): на сервере Beget оказалось две инсталляции WordPress в одной папке. Одна — реально работающая, в ~/cmpnn.ru/public_html/. Вторая — старая, в ~/public_html/, симлинком на которую был оверрайдящий .htaccess route.

REST API подключался к старой инсталляции (потому что DNS клиента смотрел туда), а лайв-сайт показывал контент из новой. Все наши правки уходили в холостую БД, на лайве их никто никогда не видел.

Лечится за полчаса: удаление симлинка, перенос всех скопленных правок в живую БД, проверка REST-эндпоинта. Но обнаружить это без SSH невозможно — REST отдавал 200 и говорил «всё сохранил».

Это типичная история кэша-который-не-кэш. Поэтому у нас в чек-листе каждого первого месяца есть пункт «убедиться, что мы пишем туда, откуда отдаётся прод».

Что в итоге

За первый месяц на этом проекте мы закрыли:

• полный SEO-аудит 573 URL с P0/P1/P2 — один прогон скрипта, ~8 минут;
• 26 multi-H1 страниц через прямую правку post_content;
• 36 пустых описаний товаров заполнены по 4 шаблонам;
• 19 meta description на коммерческих посадочных (включая разгадку кэш-блокера);
• alt-теги с 21% покрытия до 100% — все 8 255 изображений;
• 2 редиректа дублей, 3 фикса noindex-регрессий;
• sitemap почищен с 12 до 5 файлов.

Это не «опубликовать кейс с цифрами роста трафика +35%» — рост требует 3–6 месяцев и зависит от множества факторов. Это — видимый фундамент, без которого никакой рост невозможен. После таких правок сайт перестаёт «гасить себя самостоятельно», и дальше уже можно говорить про семантику, контент и кластеры.