Більшість чек-лістів з SEO виглядають так: «перевірте robots.txt», «переконайтеся, що сайт індексується». Що саме перевіряти і що вважати поганим результатом, не сказано.

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

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

Порядок важливіший за повноту

Головна помилка самостійного аудиту: почати з того, що легше перевірити, а не з того, що дорожче коштує.

Перевірка 1. Чи не закрито сторінку від індексації

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

Що зробити. Відкрийте ваш-сайт.com/robots.txt у браузері. Шукайте рядок Disallow: /.

Потім відкрийте будь-яку сторінку, натисніть праву кнопку, «Переглянути код сторінки» і пошукайте noindex.

Що погано. Disallow: / без уточнень закриває весь сайт. <meta name="robots" content="noindex"> на сторінці, яка має ранжуватися, закриває її.

Швидка перевірка з командного рядка:

curl -s https://ваш-сайт.com/robots.txt | head -20

Перевірка 2. Чи є текст у HTML до виконання скриптів

Це те, на чому обпеклися ми самі, і історія коштувала нам двохсот днів.

Наш власний сайт на попередній платформі віддавав роботу 70 символів видимого тексту на головній сторінці. Весь інший текст малювався скриптом уже після завантаження. Посилань у коді було нуль, тегів h1 нуль, а перед контентом крутилася заставка на 8,3 секунди.

Сайт існував, відкривався і виглядав нормально. У пошуку його не було.

Що зробити. Відкрийте головну, права кнопка, «Переглянути код сторінки». Тепер пошукайте в цьому коді будь-яке речення зі свого сайту.

Що погано. Речення немає. Це означає, що текст малюється скриптом, і робот може його не побачити.

Друга частина перевірки, порахуйте посилання. Якщо в коді головної немає тегів <a href, у вас немає внутрішньої перелінковки взагалі.

curl -s -A "Mozilla/5.0" https://ваш-сайт.com/ | grep -o '<a href' | wc -l

Нуль це аварія. Менше десяти на головній сторінці це мало.

Перевірка 3. Чи знає пошуковик про вашу карту сайту

Тут теж наша власна історія. Карта сайту у нас існувала, генерувалася при кожній збірці і нормально віддавалася на запит. Але її ніхто нікуди не надіслав.

Різниця між «карта є» і «карту відправлено» виглядає формальністю. Вона не формальність: пошуковик не піде шукати ваш файл навмання.

Що зробити. Два кроки.

Відкрийте ваш-сайт.com/robots.txt і перевірте, чи є там рядок Sitemap: https://....
Зайдіть у Search Console, розділ «Карти сайту», і подивіться, чи стоїть там ваш файл і коли його востаннє зчитували.

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

Перевірка 4. Чи не дублюються адреси

Одна й та сама сторінка часто доступна за кількома адресами одразу: зі слешем і без, з www і без, через http і https.

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

Що зробити. Перевірте всі чотири варіанти і подивіться, куди вони ведуть:

for u in http://сайт.com https://сайт.com https://www.сайт.com https://сайт.com/; do
  curl -s -o /dev/null -w "%{http_code} %{redirect_url}\n" "$u"
done

Що добре. Три варіанти віддають 301 і ведуть на один четвертий.

Що погано. Кілька варіантів віддають 200. Це і є дублювання.

Окремо перевірте тег link rel="canonical" на сторінці: він має вказувати на ту саму адресу, за якою сторінка відкривається. Канонічний тег, що веде на адресу з редиректом, це поширена і шкідлива помилка.

Перевірка 5. Заголовок сторінки

Що зробити. Зберіть заголовки всіх сторінок і подивіться на довжину.

curl -s -A "Mozilla/5.0" https://сайт.com/сторінка | grep -o '<title>[^<]*'

Пороги, які ми використовуємо:

Що	Норма
Довжина заголовка	до 60 символів, максимум 65
Унікальність	кожна сторінка свій
Головне слово	ближче до початку

Що станеться, якщо заголовок довший: пошук обріже його на видачі. Людина побачить обрубок і клікне на сусідній результат.

Ми міряли це на своїй мережі і знайшли 8 статей із 17, де заголовок або опис вилазив за межу. Це на сайтах, які робили ми самі й уважно. На звичайному сайті частка зазвичай вища.

Перевірка 6. Опис сторінки

Що зробити. Той самий підхід, тег meta name="description".

Норма: до 160 символів, свій для кожної сторінки, з дією або цифрою всередині.

Що погано: опису немає зовсім, він однаковий на всьому сайті, або він довший за 160 символів і обрізається.

Опис не впливає на позицію напряму. Він впливає на те, чи клікнуть, а це вже впливає на все інше.

Перевірка 7. Один h1 на сторінку

Що зробити:

curl -s -A "Mozilla/5.0" https://сайт.com/сторінка | grep -o '<h1' | wc -l

Що добре. Рівно 1.

Що погано. Нуль означає, що найсильніший сигнал про тему сторінки просто відсутній. Більше одного розмиває сигнал.

Друга частина: перевірте порядок заголовків. h2 не має йти після h4, а h3 не має стояти там, де за змістом h2. Порядок заголовків це зміст документа для машини.

Перевірка 8. Внутрішні посилання

Це найчастіша прихована проблема, і виглядає вона нешкідливо.

На своєму флагмані ми виявили, що 49 матеріалів із 50 не мали жодного вхідного посилання з інших сторінок сайту. Вони існували в карті сайту і більше ніде. Для пошуку це сторінки-сироти: формально вони є, фактично до них ніхто не веде.

Що зробити. Візьміть будь-яку статтю і спитайте себе: з яких сторінок сайту на неї можна перейти? Якщо відповідь «тільки зі списку всіх статей», цього мало.

Норма, яку ми поставили собі: мінімум три вхідних посилання на кожен матеріал, у середньому чотири.

Найпростіше лікування: блок «схожі матеріали» внизу кожної статті, зібраний за темою, а не випадково.

Перевірка 9. Биті посилання

Що зробити. Пройдіться по всіх адресах з карти сайту і подивіться коди відповіді.

curl -s https://сайт.com/sitemap.xml \
  | grep -o '<loc>[^<]*' | sed 's/<loc>//' \
  | while read u; do
      echo "$(curl -s -o /dev/null -w '%{http_code}' -A 'Mozilla/5.0' "$u") $u"
    done

Важлива деталь, на якій ми самі помилилися. Спершу ми робили це без -A "Mozilla/5.0", тобто без підпису браузера. Отримали 403 на всіх вісімдесяти адресах і вирішили, що сайт зламаний. Насправді захист від ботів просто не пускає запит без підпису.

Ми перевірили 216 адрес на 18 сайтах. 96% віддали 200, вісім адрес виявилися редиректами, і всі вісім були зосереджені на трьох сайтах. Тобто проблема майже завжди не розмазана по сайту, а сидить в одному місці.

Що погано. Будь-який 404 у карті сайту. Карта це список того, що ви пропонуєте індексувати, і мертві адреси в ній підривають довіру до всієї карти.

Редирект у карті це не аварія, але це зайвий крок для робота, і адресу варто оновити.

Перевірка 10. Швидкість

Що зробити. PageSpeed Insights, безкоштовно, вкладка «Мобільні». Дивіться не на загальну оцінку, а на три показники.

Показник	Добре	Погано
LCP, час до головного елемента	до 2,5 с	понад 4 с
INP, відгук на дію	до 200 мс	понад 500 мс
CLS, стрибки верстки	до 0,1	понад 0,25

Що з цим робити перш за все. У малого бізнесу причина повільності майже завжди одна з трьох: величезні фотографії, підключені шрифти, які ніде не використовуються, і три різні системи аналітики одночасно.

Чесно про пріоритет: швидкість рідко буває причиною того, що сторінки немає в пошуку. Вона впливає на позицію, коли все інше вже зроблено. Лагодити її раніше за перевірки 1 та 2 це витрачати час не туди.

Перевірка 11. Мобільна версія

Що зробити. Відкрийте сайт на справжньому телефоні, а не в зменшеному вікні браузера.

Що дивитися:

чи є горизонтальний скрол. Його не має бути ніколи;
чи попадаєте пальцем у кнопки з першого разу;
чи читається текст без збільшення;
чи не перекриває щось контент: банер про куки, чат, кнопка «нагору».

Найчастіша помилка, яку ми бачимо: віджет чату, що закриває кнопку заявки саме на телефоні.

Перевірка 12. Розмітка дат

Ця перевірка потрібна тим, у кого є блог або новини.

Ми перевіряли дванадцять сторінок статей у відомих компаній. Дев’ять із дванадцяти розмічають дату публікації. Дату оновлення розмічають лише шість із дванадцяти.

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

Що зробити. Подивіться в коді сторінки, чи є datePublished і dateModified у розмітці.

Окремо. Ми перевірили ще й сторінки-списки блогів: там дату розмічають лише чотири з вісімнадцяти. Це виглядає гірше, ніж є: індексується і ранжується стаття, а не список. Але якщо ви робите аудит своїми скриптами і читаєте список, ви отримаєте висновок, що дат немає ніде.

Що робити з результатами

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

Перевірте себе

Що робити завтра

Перевірки 1 і 2. Разом п’ять хвилин, і вони закривають найдорожчі помилки.
Перевірка 3. Якщо в консолі порожньо, відправте карту сайту сьогодні.
Перевірка 9 однією командою зверху. Випишіть усі коди, що не 200.
Перевірки 5, 6, 7 по всіх сторінках. Це нудно і дає найшвидший видимий результат.
Решта за порядком зі шкали.

Це наш підхід і наш досвід, а не універсальне правило. Якщо сайт великий або на ньому вже є трафік, який ви боїтеся зламати, порадьтеся зі спеціалістом перед тим, як міняти редиректи й канонічні адреси: саме на цих двох речах найлегше зробити гірше.

Чого ці дванадцять перевірок не пояснюють

Вони не замінюють роботу з контентом: семантичне ядро, тексти і посилання це окремий, довший шлях.

Вони пояснюють, чому сторінки немає в пошуку. Вони не пояснюють, чому вона є, але на сімдесятій позиції.

Ми пройшли цей шлях на своїй мережі: усі технічні перевірки зелені, індексація 22 сторінки з 24, а показів сотні при нулі кліків. Причина була не технічна. Сторінки були тонкі, по 580 слів проти двох-чотирьох тисяч у тих, хто стоїть вище, а доменам було два тижні.

Технічний аудит прибирає перешкоди. Він не додає причин показувати вас вище.