SEO-аудит WordPress: що перевірити й виправити першим

SEO-аудит WordPress — це перевірка сайту на WordPress, яка охоплює проблеми, характерні саме для цієї CMS (налаштування видимості для пошукових систем, вивід SEO-плагінів, автоматично створені архіви, сторінки вкладень, розмітку теми та перевантаження плагінами), а також звичні перевірки сканування, індексації й контенту. Мета — короткий список виправлень, впорядкований за пріоритетом, і першими в ньому стоять речі, що блокують індексацію.

На WordPress працює величезна частка інтернету, і більшість SEO-проблем таких сайтів спричиняє не саме ядро, а стандартні налаштування, плагіни й теми. У цьому посібнику — що перевіряти, де WordPress зазвичай дає збій і що виправляти насамперед.

Навіщо сайту на WordPress окремий SEO-аудит?

Сайту на WordPress потрібен аудит з урахуванням специфіки CMS, бо вона створює URL, теги й файли, яких ви ніколи не писали вручну. Архіви тегів, сторінки авторів, сторінки вкладень, віртуальний robots.txt і автоматично згенерована карта сайту є «з коробки». Плагіни й теми додають поверх цього власний вивід.

Загальний аудит при цьому нікуди не зникає. Вам потрібна база з нашого посібника про технічний SEO-аудит: сканування, індексація, редиректи та швидкість. Але на WordPress причиною знахідки зазвичай є налаштування або плагін, тож виправлення — це прапорець, заміна плагіна чи зміна теми. Код доводиться чіпати рідко.

Типові знахідки на WordPress виглядають так:

• Увесь сайт закритий noindex, бо після запуску забули зняти один прапорець.
• Два SEO-плагіни виводять кожен свій canonical і meta description.
• В індексі сотні «тонких» сторінок тегів.
• У пошуку з'являються сторінки вкладень із зображеннями замість самих записів.
• Тема з конструктором сторінок тягне важкий JavaScript і не проходить Core Web Vitals.

SEO для WordPress: чек-лист — що перевірити першим

Перевіряйте в порядку впливу. Якщо Google не може проіндексувати сайт, усе, що нижче в списку, поки не має значення.

Повний список для будь-якої платформи — у чек-листі SEO-аудиту. Нижче пояснюємо пункти, специфічні для WordPress.

Чи не блокує ваш сайт налаштування «Discourage search engines»?

Перевірте це першим. Коли в Settings → Reading (Налаштування → Читання) позначено Discourage search engines from indexing this site (в українському інтерфейсі — прохання до пошукових систем не індексувати сайт), WordPress виводить на кожній сторінці robots meta-тег noindex,nofollow. Згідно з документацією WordPress про налаштування читання, так працює з версії 5.3. До неї WordPress натомість віддавав robots.txt із Disallow: /.

Цей прапорець часто вмикають на staging-сайті, а потім він переноситься на робочий. У результаті запущений сайт так і не з'являється в Google. У тій самій документації зазначено, що опція — лише прохання, тож вона не захищає staging-сайт від сторонніх очей. Для цього використовуйте захист паролем.

Це налаштування також вимикає вбудовані карти сайту WordPress. В анонсі sitemap у WordPress 5.5 сказано, що вбудовані sitemap враховують опцію «discourage search engines». Тож якщо /wp-sitemap.xml нічого не повертає на сайті без SEO-плагіна, першим під підозру потрапляє саме цей прапорець.

Як перевірити: відкрийте будь-яку сторінку, перегляньте код і знайдіть name="robots". Потім проженіть кілька ключових URL через перевірку URL у Search Console.

Як перевірити robots.txt і карту сайту WordPress?

WordPress віддає віртуальний robots.txt, якщо в корені сайту немає реального файлу, а SEO-плагіни можуть його редагувати. Відкрийте /robots.txt у браузері й прочитайте, що там насправді. Не покладайтеся на те, що показує екран налаштувань плагіна.

На що звернути увагу:

• Заблоковані ресурси теми чи плагінів. Старі поради рекомендували закривати /wp-content/ або /wp-includes/. У вступі до robots.txt від Google застерігають від блокування ресурсів, потрібних краулерам, щоб зрозуміти сторінку. CSS і JS у /wp-content/ зазвичай належать саме до них.
• Приховування сторінок через robots.txt. Google наголошує, що robots.txt «не є механізмом, щоб не допустити вебсторінку в Google». Заблоковані URL усе одно можуть потрапити в індекс без опису. Правила докладно розібрано в нашому посібнику з robots.txt.
• Disallow і noindex на одній URL. У документації Google про noindex сказано, що сторінку з noindex не можна блокувати в robots.txt, інакше Googlebot ніколи не побачить директиву.

Типовий безпечний robots.txt для WordPress виглядає так:

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php

Sitemap: https://example.com/wp-sitemap.xml

Перевірка карти сайту

Ядро WordPress генерує карти сайту за адресою /wp-sitemap.xml з версії 5.5. Вони охоплюють публічні типи записів, таксономії, архіви авторів і головну сторінку, за замовчуванням до 2 000 записів в одному файлі sitemap (анонс ядра WordPress). SEO-плагіни можуть вимикати вбудовану карту сайту й віддавати власну.

Що перевірити:

1. Рівно одне джерело sitemap — і саме воно надіслане в Search Console та вказане в robots.txt.
2. Жодних URL з noindex, редиректами чи 404 у карті сайту. Поширений випадок: архіви тегів закриті noindex, але досі є в sitemap.
3. Жодних порожніх чи приватних типів записів (форми, шаблони конструктора сторінок, контент для учасників), відкритих як записи sitemap.

Які сторінки WordPress створюють дублі й «тонкий» контент?

WordPress автоматично створює кілька видів архівних сторінок. Багато з них повторюють контент, що є деінде, або містять по одному-два записи. Саме звідси походить більша частина «роздутого» індексу на WordPress.

На старих сайтах варто уважніше придивитися до сторінок вкладень. У WordPress 6.4 у ядрі з'явилася опція wp_attachment_pages_enabled. Згідно з нотаткою про сторінки вкладень у WordPress 6.4, на нових інсталяціях вона за замовчуванням вимкнена, тож сторінки вкладень перенаправляють на файл. Сайти, що існували до оновлення, зберігають ці сторінки увімкненими. Тому на старому сайті досі можуть бути тисячі URL лише із зображеннями, які Google може проіндексувати. Такими URL часто заповнюються звіти Search Console на кшталт Crawled – currently not indexed.

З архівами рубрик інша історія. Добре оформлена сторінка рубрики зі вступом і підібраними записами може ранжуватися, тож наповніть її справжнім контентом і залиште індексованою.

Чи не конфліктують два SEO-плагіни через ваші теги?

Це одна з найпоширеніших знахідок на WordPress. Два SEO-плагіни (або SEO-плагін плюс тема з вбудованими SEO-функціями) кожен виводять title, meta description, canonical і schema-розмітку. У підсумку на сторінці два canonical або два суперечливі теги og:.

У посібнику Google з консолідації дубльованих URL окремо застерігають від зазначення різних canonical для однієї сторінки різними способами й просять використовувати абсолютні URL. Якщо в коді сторінки два рядки rel="canonical", ви знайшли проблему. Залиште один SEO-плагін, вимкніть SEO-вивід у темі й перевірте ще раз. Загальні правила — у посібнику з тегу canonical.

Поки ви в коді сторінки, перевірте також:

• Шаблони title і meta. Шаблони на кшталт %title% | %sitename% — це нормально. А відсутні шаблони, через які кожна сторінка товару називається «Shop | Brand», — ні.
• Canonical веде на кінцеву URL: HTTPS, правильна версія з www чи без, той самий стиль кінцевої скісної риски, що й у постійних посиланнях.
• Canonical на сторінках пагінації. Друга сторінка архіву має вказувати canonical на себе, а не на першу.

Як теми й конструктори сторінок впливають на SEO WordPress?

Тема керує вашим HTML: структурою заголовків, тим, чи є основний контент у початковому HTML, і тим, скільки CSS та JavaScript завантажує кожна сторінка. Два сайти з однаковими плагінами можуть отримати зовсім різні оцінки лише через тему.

Що перевірити:

• Один H1 на сторінці, і в ньому — назва сторінки. Деякі теми обгортають логотип в H1 на кожній сторінці або роблять заголовки записів H2.
• Контент у сирому HTML. Вкладки, акордеони й слайдери, що підвантажують текст лише після виконання JavaScript, можуть приховати його від краулерів, які не рендерять сторінки. Порівняйте код сторінки з тим, що бачите в браузері.
• Внутрішні посилання у справжніх тегах <a href>. Мегаменю й кнопки «завантажити ще» на JavaScript-подіях часто залишають глибокі записи без посилань. Див. внутрішня перелінковка для SEO.
• Залишки демоконтенту. Імпортовані демо тем залишають в індексі зразкові сторінки, елементи портфоліо й записи «Hello world!».

Чому сайти на WordPress повільні і що перевіряти?

На WordPress повільні сторінки зазвичай спричиняють забагато плагінів, важкі конструктори сторінок, неоптимізовані зображення й хостинг без кешування сторінок. Спершу виміряйте: подивіться польові дані Core Web Vitals у Search Console або PageSpeed Insights, адже порогові значення (LCP ≤ 2,5 с, INP ≤ 200 мс, CLS ≤ 0,1) застосовуються до 75-го процентиля реальних відвідувань. Кожну метрику пояснює наш посібник з Core Web Vitals.

Специфічні для WordPress причини, які варто шукати:

• Плагіни, що завантажують ресурси на кожній сторінці. Скрипт контактної форми, слайдера чи попапу вантажиться на всіх 500 записах, хоча використовується лише на одній сторінці.
• Велике головне зображення як елемент LCP — без preload, а іноді й помилково з lazy load.
• Немає кешу сторінок, тож кожен візит запускає PHP і запити до бази даних.
• Кілька плагінів оптимізації одночасно, які можуть ламати мініфікацію один одного й спричиняти зсуви макета.
• Сторонні вбудовування (віджети чату, каруселі відгуків), що сповільнюють взаємодію і погіршують INP.

Спершу видаляйте, потім оптимізуйте. Деактивація трьох непотрібних плагінів часто дає більше, ніж тонке налаштування десяти параметрів.

Що має перевіряти аудит WordPress для AI-пошуку?

На WordPress перевірки для AI-пошуку здебільшого зводяться до доступу та зрозумілості. Чи можуть AI-краулери отримати ваші сторінки, чи є основний текст в HTML і чи чітко бізнес ідентифікований у структурованих даних? WordPress додає власні ризики: плагіни безпеки та налаштування блокування ботів у CDN можуть непомітно відсікати AI-краулерів.

Перевірте:

• robots.txt і правила файрвола для пошукових і навчальних AI-ботів. Плагін безпеки може блокувати ботів, яких дозволяє robots.txt.
• Розмітку Organization з sameAs — посиланнями на ваші офіційні профілі, яку один раз виводить SEO-плагін.
• Керування сніпетами, як-от nosnippet чи max-snippet, які плагін помилково виставив на весь сайт.

У чек-листі оптимізації для AI-пошуку описано задокументованих краулерів кожної платформи. Щоб перевірити ці пункти на власному сайті, безкоштовний SEO-аудит від SEORecheck покаже описані вище налаштування індексації, дубльовані теги, проблеми з картою сайту й архівами, а також доступ AI-краулерів у robots.txt, керування сніпетами, текст, видимий лише після JavaScript, і розмітку Organization/sameAs.

Як розставити пріоритети у виправленнях SEO на WordPress?

Виправляйте в такому порядку: блокери індексації, потім дубльовані сигнали, потім «роздутий» індекс, потім швидкість, потім контент і структуровані дані. Сайт, закритий noindex, нічого не виграє від швидших зображень. Сайт із 3 000 «тонких» сторінок тегів отримає більше від їх прибирання, ніж від переписування одного meta description.

Практичний план:

1. Дні 1–30: налаштування видимості для пошукових систем, robots.txt, одна карта сайту, один SEO-плагін, виправлення canonical і редиректів.
2. Дні 31–60: noindex або видалення «тонких» архівів, редиректи сторінок вкладень, прибирання демоконтенту, виправлення заголовків у темі.
3. Дні 61–90: чистка плагінів і Core Web Vitals, внутрішня перелінковка, структуровані дані, доступ AI-краулерів.

Потім проведіть аудит ще раз, щоб підтвердити, що кожну проблему справді виправлено. Приклад звіту показує, як виглядає план із пріоритетами, а порівняння під час повторної перевірки — як після другого сканування відстежуються виправлені, покращені, невирішені й нові проблеми.

Головне

• Починайте кожен SEO-аудит WordPress із Settings → Reading (Налаштування → Читання) і робочого robots.txt. Один прапорець може викинути з індексу весь сайт.
• Залишайте один SEO-плагін і одне джерело sitemap. Дубльовані canonical і meta-теги виникають через конфлікти плагінів і теми.
• Сторінки тегів, авторів, дат і вкладень — головне джерело «роздутого» індексу на WordPress. На старих сайтах сторінки вкладень можуть бути досі увімкнені.
• Ніколи не поєднуйте Disallow і noindex на одній URL. Google не побачить noindex на сторінці, яку йому заборонено сканувати.
• Проблеми зі швидкістю зазвичай спричиняють плагіни, конструктори сторінок і зображення. Видаліть те, чим не користуєтеся, перш ніж щось налаштовувати.
• Перевірте, чи не блокують плагіни безпеки й налаштування CDN тих AI-краулерів, яких ви хочете пускати.