Yoast и RankMath настраивают title, description и один canonical на странице. Архитектуру сайта они не трогают — а именно она плодит дубли из архивов тегов, страниц вложений и дат, открывает юзернеймы через REST API и начинает конфликтовать сама с собой, если плагинов SEO в сборке два. Разбираю 7 конкретных поломок WordPress, которые плагин не увидит, и свою историю с тегами, которая полгода заливала Search Console «дубликатами».
«У нас Yoast, SEO настроено» — говорю это клиенту в лицо на каждом втором аудите сайта на WordPress, но уже в кавычках с сарказмом. Yoast и RankMath реально хороши в своей зоне ответственности: мета-теги, sitemap, базовая схема, подсказки по читаемости. Зона ответственности узкая. Всё, что происходит на уровне архитектуры CMS — а WordPress генерирует URL сам, без спроса — плагин не трогает и не обязан.
1. Дубли, которые создаёт сам WordPress, а не контент-менеджер
Поставь свежий WordPress, напиши один пост с одним тегом — и у тебя уже минимум четыре URL с одним и тем же контентом: сама запись, архив тега, архив категории и архив автора (если автор один на блог — его архив дублирует весь блог целиком). Добавь вложения — у каждой загруженной картинки WordPress по умолчанию создаёт собственную HTML-страницу /?attachment_id=123 с title из имени файла и почти без текста.
| Тип дубля | Где лежит | Чем лечится |
|---|---|---|
| Архив тега | /tag/название/ | noindex, если тегов больше, чем нужно для навигации; или убрать теги вовсе на малом блоге |
| Страница вложения | /?attachment_id= или /имя-картинки/ | В настройках медиа — редирект на сам файл, опция есть в Yoast/RankMath, по умолчанию выключена |
| Архив автора при одном авторе | /author/admin/ | noindex или отключить архивы авторов целиком |
| Архив по дате | /2026/10/ | noindex, почти никогда не несёт пользы для поиска |
Ни одна из этих страниц не ломает сайт визуально. Все рендерятся, все отдают 200. Проблема не в том, что они есть — проблема в том, что без явного noindex Google их индексирует как тонкий, частично дублирующий контент, и это размывает авторитет между четырьмя версиями одного текста вместо того, чтобы концентрировать его на одной.
2. REST API отдаёт список логинов, даже когда ты его не просил
Зайди на любой чужой сайт на WordPress и открой site.ru/wp-json/wp/v2/users. Если никто не закрыл эндпоинт — получишь JSON со списком всех авторов, их отображаемыми именами и, что хуже, слагами, которые на дефолтной установке совпадают с логином. Это не SEO-проблема в узком смысле, это дырка в безопасности, которая напрямую аффектит SEO: brute-force по известным логинам через wp-login.php или через xmlrpc.php (протокол pingback — ещё одна древняя дверь, которую почти никогда не закрывают) — частая причина, почему слабо защищённый WordPress взламывают и заливают туда дорвей-страницы с японскими иероглифами или фарма-спамом, который потом ловит ручная санкция.
Закрывается без плагина: disallow_file_edit в wp-config.php, лимит попыток входа (плагин с узкой задачей, не тот же Yoast), запрет xmlrpc.php через правило в .htaccess или nginx, если pingback-трекбэки реально не нужны — а они почти никому не нужны в 2026-м.
3. Два SEO-плагина одновременно — тихий, незаметный конфликт
Регулярно вижу: клиент когда-то поставил Yoast, потом новый подрядчик поставил RankMath «потому что он лучше», старый не удалил. Оба плагина продолжают генерировать свой <meta name="robots">, свой <link rel="canonical">, свои og-теги — в голову страницы попадают оба набора. Браузер и большинство ботов возьмут первый встреченный тег, но что именно первым — зависит от порядка загрузки хуков, который может незаметно смениться при обновлении одного из плагинов. Результат — canonical, который «иногда» указывает не туда, куда настроено в админке, и это невозможно поймать глазами в самой админке, только через «Просмотр кода страницы» в браузере.
Проверка за минуту: открой исходный код любой страницы, найди все вхождения rel="canonical" и name="robots". Если больше одного — удаляй один из двух плагинов полностью, не просто деактивируй.
4. Конструктор страниц тащит в Core Web Vitals больше, чем контент
Elementor, Divi, WPBakery — удобно редактировать визуально, дорого по весу страницы. Один блок «три колонки с иконками» в Elementor может подтянуть 200+ КБ собственного CSS и JS на страницу, где по факту нужно три div. На PageSpeed Insights это видно сразу: «Уменьшите неиспользуемый CSS» и «Уменьшите неиспользуемый JavaScript» на 400-900 КБ на странице, где текста на экран A4. LCP и INP страдают первыми — конструктор грузит интерактивность раньше, чем контент.
Это не повод отказываться от конструктора совсем, если контент-команда реально в нём работает без разработчика. Повод — убрать с конструктора страницы, которые редактируются раз в год (услуги, о компании), и оставить его только там, где контент-менеджер правит сам и часто.
5. Смена структуры постоянных ссылок без редиректов
Настройки → Постоянные ссылки — одна галочка меняет структуру URL всего сайта в одно нажатие, WordPress не предупреждает, не создаёт редиректы сам. Переключили с /?p=123 на /%postname%/ или добавили дату в структуру — все старые ссылки, включая входящие с других сайтов и из органики, превращаются в 404 в ту же секунду.
Моя ошибка: полгода чистил теги, прежде чем понял источник проблемы
Вёл блог на WordPress для сайта услуг — контент-менеджер клиента ставил по 3-5 тегов на каждый пост, по привычке с других платформ, где теги работают как хэштеги. Через год в блоге было больше уникальных тегов, чем постов. Каждый тег — отдельный архив, индексируемый по умолчанию. В Search Console раздел «Страницы» показывал сотни URL со статусом «Дубликат, канонический URL не выбран пользователем» — и я две недели разбирал это как проблему с canonical-тегами на самих постах, хотя с постами всё было в порядке.
Проблема была в архивах тегов: контент на них состоял из обрывков текста постов (стандартный excerpt), а сами URL никогда явно не помечались канониклом на что-либо — Google сам решал, что это дубликат чего-то, и решал неправильно. Фикс — не почистить теги вручную (их были сотни), а глобально поставить noindex на все архивы тегов через настройки Yoast (вкладка «Типы контента» → «Архивы тегов» → Показывать в результатах поиска: Нет) и обязать контент-менеджера ставить не больше одного тега на пост, который реально что-то группирует. Через полтора месяца «Дубликаты» в Покрытии ушли почти до нуля.
Ты вообще смотрел, сколько уникальных тегов накопилось в твоём WordPress-блоге за последний год, или просто продолжаешь ставить теги по привычке?
Про выбор движка и когда WordPress — правильный вариант, а когда нет: конструктор, CMS или свой движок. Про аналогичные грабли на Битриксе — SEO на 1С-Битрикс. Про скорость как фактор, а не только «в топ надо» — оптимизация Core Web Vitals.