Технічний аудит сайту: покрокова інструкція для тих, хто не готовий переплачувати

Почнемо з того, що не існує точного списку параметрів, які потрібно перевіряти, роблячи технічний аудит сайту. Кожне агентство або SEO-фахівець робить його по-своєму. Тому не потрібно боятися помилитися.

При цьому важливо зрозуміти 2 моменти:

1. Технічний аудит – це не вивантаження з Netpeak Spider або Screaming Frog. Хоча саме їх найчастіше і видають за аудит на біржах фрілансу. Це софт, який дає змогу зібрати частину (!) інформації, не більше.
2. Пишіть в аудит тільки те, що потрібно виправити, а не все, що ви перевірили. Краще це буде 1-2 аркуші реально важливих рекомендацій у вигляді ТЗ для програміста, ніж 10-20 аркушів опису того, що ви перевірили.

Другий пункт спірний. Якщо ви надішлете замовнику 5 правок з технічної частини та напишете, що все інше в порядку, у нього точно виникне питання – що ви маєте на увазі під «все інше»? Може ви всього 5 параметрів перевірили, а може 50…

Я рекомендую писати тільки те, що потрібно правити, виходячи з того, що аудит буде проводитися за цією інструкцією. І я точно знатиму, що саме перевірялося. Або виходячи з того, що ви будете робити його для свого сайту. А ось якщо це робота для когось, тоді додавайте посилання на чек-лист, за яким ви робили перевірку. Або ж перерахуйте у звіті все, що перевірили.

І останнє, якщо вам потрібен повний технічний аудит сайту – можете замовити його у нас. У рамках цієї статті будемо розбирати тільки найважливіші моменти, які в змозі перевірити новачок. Просто немає сенсу розписувати тут, як перевірити скрипти і стилі в коді або щось подібне. Ну не зможе людина без досвіду цього зробити, скільки не розписуй. Та й правити такий код замовник буде не завжди. Зате є багато помилок, яких припускаються дуже часто, а правляться вони легко.

Склеювання дзеркал

Якщо ви не знаєте що таке дзеркала сайту, як визначити головне, як їх перевірити і що значить склейка – зробіть паузу та прочитайте цю статтю. А тут я розпишу тільки план перевірки, без детальних пояснень.

Перед аудитом уточнюємо у замовника, чи є у сайту дзеркала. Щоб у разі виявлення дублів одразу розуміти, чи це дзеркала, які потрібно перевірити і склеїти за потреби, чи хтось скопіював сайт і з цим потрібно боротися. Другий варіант ми будемо розбирати, але не в рамках технічного аудиту. А ось якщо замовник все-таки робив дзеркала – це потрібно знати. Але це буває рідко, тому перевіряємо тільки на http/https, www та слеші.

Порядок дій:

1. Беремо будь-яку сторінку сайту.

2. Складаємо список можливих адрес з http/https, з www і без, зі слешем на кінці та без. Приклад:

3. Перевіряємо відповіді сервера для цих адрес (у статті за посиланням вище, все це розписано). Залежно від результатів перевірки пишемо ТЗ для програміста.

Якщо дзеркала склеєні

Тобто, одна адреса віддає код 200, а решта 301 редирект на головне дзеркало. Тоді жодних дій не потрібно.

Якщо є ланцюжки редиректів

У такому разі пишемо програмісту таке:

Якщо дзеркала склеєні частково

Наприклад, редиректи з http на https налаштовані, а з www на адреси без www – ні. У такому разі пишемо програмісту, щоб налаштував відсутні 301 редиректи на головне дзеркало та вказуємо з яких адрес на які.

Якщо дзеркала не склеєні

Спершу визначаємо головне дзеркало. Після чого пишемо програмісту, що дзеркала не склеєні і потрібно налаштувати 301 редирект з усіх варіантів адрес (вказуємо список) прямі 301 редиректи на головне дзеркало (вказуємо яке).

HTTPS

Не знаєте, що таке HTTPS, SSL, як вони працюють та який протокол кращий для сайту? Тоді робимо ще одну паузу і читаємо статтю за посиланням. А вже після цього перевіряємо наявність HTTPS та чи правильно він налаштований.

Варіант 1

Якщо SSL-сертифікат у сайту встановлений, і він працює за HTTPS протоколом, ви це виявите на попередньому кроці, коли перевірятимете склейку дзеркал. У такому разі цей пункт можна пропустити.

Варіант 2

Якщо сайт доступний тільки за HTTP і при цьому він новий (після запуску минуло кілька днів/тижнів), пишіть у ТЗ для програміста, що потрібно перенести сайт на HTTPS. Але з новими сайтами рідко приходять на просування, тож це швидше для довідки.

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

Якщо робите аудит для себе – плануйте перехід на HTTPS, ви все одно до цього прийдете.

Додаткова перевірка за бажанням

Правильність налаштувань сайту при переході на HTTPS зазвичай перевіряють у момент проведення цих робіт. Тому тут рідко бувають проблеми. Але випадки бувають різні, а перевірка через SSL Checker займе кілька хвилин. Чому б і не подивитися… Гуглите «SSL Checker», берете перший-ліпший та перевіряєте сайт через нього. Для сайту PROSUVER, який працює на https, результат перевірки має такий вигляд:

або так:

Якщо під час перевірки у вас також усе зелене – все ок. Якщо ні – потрібно дивитися, у чому саме проблема. Не розбираєтеся – і не потрібно, напишіть тоді в ТЗ програмісту, що під час перевірки таким-то чекером ви отримали такий-то результат. І потрібно подивитися, що це за проблеми.

Robots.txt

Практично будь-який чек-лист технічного аудиту сайту рекомендує перевірити robots.txt. Але ось проблема – як його перевірити новачкові, який тільки вчиться робити аудити… Відповідь проста – ніяк. Щоб дійсно проаналізувати robots, потрібен досвід. І вже тим більше потрібен досвід, щоб прописати для нього відсутні директиви. Але потрібно ж із чогось починати. Тож спробуємо.

Перевіряємо його наявність

Robots.txt – це файл, який показує пошуковим системам, що саме на сайті їм дозволено обробляти. Знайти його можна за адресою:

Зверніть увагу – адреса може бути тільки такою. Підставляйте свій домен та перевіряйте. Якщо сторінка буде недоступна, значить robots.txt відсутній. У такому разі пишіть у ТЗ, що його потрібно додати. За його наявності ви побачите сторінку такого типу:

Чи є посилання на карту сайту

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

Доменне ім’я, звісно, має бути сайту, який ви перевіряєте. А ось остання частина адреси може бути різною. Я навів 2 варіанти, але можуть бути й інші. Якщо такого рядка немає – пишіть програмісту:

При цьому url карти сайту ви не вказуєте. Не зрозуміло, чи створена вона взагалі і яка в неї буде адреса (а це залежить ще й від способу створення). Залиште це програмісту.

Якщо такий рядок є, тоді копіюйте посилання та відкривайте в браузері. Ваше завдання переконатися, що воно відкривається. Як виглядає карта сайту, покажу в наступному пункті. Відкривається – нічого робити не потрібно. Не відкривається – пишіть програмісту, що посилання на xml мапу в robots.txt є, але воно не відкривається. Потрібно перевірити й усунути проблему.

Дивимося вміст

Тут складніше. На скріні вище у нас є блок, який починається з «User-agent: *». Зірочка позначає, що правила нижче поширюються на всі пошукові системи. А потім іде список директив Allow і Disallow, які показують, що пошуковому роботу сканувати можна, а що не можна. Перевірити їх без досвіду складно. Тому підемо іншим шляхом.

Запитайте у замовника, яка у сайту CMS (система управління контентом, вона ж «движок сайту»). Потім погуглите – правильний robots.txt для… і вказуєте, яка CMS. На скрині вище – це robots.txt для WordPress. Для інших движків або для самописних сайтів він буде іншим.

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

А ось якщо в рекомендованому варіанті ви бачите 15-20 рядків, а за фактом їх 3 – ось тоді потрібно розбиратися та вникати більш детально. Досвідчений SEO-фахівець на даному етапі складе правильний robots.txt та додасть його до ТЗ з правкою «Потрібно замінити». У вашому випадку є варіанти:

1. Шукаєте інформацію в інтернеті й розбираєтеся. Базу зрозумієте швидко. А ось скласти правильний варіант все одно буде складно.
2. Запитуєте поради у більш досвідченого SEO-фахівця. Кілька таких обговорень і почнете потроху розбиратися.
3. Пишете в ТЗ, що рекомендований robots.txt має бути таким… (посилаєтеся на базовий варіант для вашого движка), а зараз він такий… (вказуєте поточний) та запитуєте в програміста, чому так. А потім уже в процесі обговорення приходите до якогось рішення.

Варіант 1 підійде для випадків, коли робите аудит технічної частини сайту для себе і запитати немає в кого. З другим зрозуміло – якщо є в кого питати, завжди краще запитати, це сильно заощадить час на навчанні. Третій – це нормальний варіант для SEO-фахівця-початківця, якщо на стороні замовника є досвідчений програміст.

Що ще може збити вас з пантелику:

• Може бути прописаний «User-agent: *» з блоком директив. А нижче «User-agent: GoogleBot» і знову список директив. Таких повторів може бути 3 і навіть більше. Це нормально. Деякі вважають за краще дублювати директиви для кожної ПС окремо або є необхідність писати різні правила для різних ботів.
• Зустрічається директива «Host». Вона вже не потрібна. Можна прибирати.
• Якщо бачите «Clean-param:» – зазвичай це не потребує коригувань. Це, швидше, показник, що роботс на цьому сайті робив хтось із розумінням процесу. Не завжди, але частіше саме так.

Sitemap.xml

Sitemap.xml – це карта сайту для пошукових систем, щоб вони розуміли, які сторінки є на сайті та що потрібно індексувати. Для PROSUVER вона доступна за адресою:

Виглядає так:

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

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

Перевіряємо наявність

Мабуть, це основне завдання для новачків. Потрібно щоб карта хоча б була. Як її шукати?

Почніть із простого – трохи вище я дав дві адреси, міняйте домен та перевіряйте за ними. Перший – це стандартний шлях, другий – для карт, які були згенеровані плагіном Yoast SEO (часто зустрічається). Ще варіант – у цих url-адресах замість sitemap.xml, підставте sitemap.xml.gz. Іноді карти можуть архівуватися.

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

Перевіряємо посилання

Якщо ви побачите карту на 10 000 url-адрес, пропозиція перевірити її вміст може здатися вам нереальним завданням. Але перевіряти все і не потрібно. В ідеалі має бути так:

• не повинно бути дублювання адрес;
• у sitemap.xml містяться тільки сторінки, які мають бути проіндексовані.

Дублі зустрічаються не часто і виявляються скоріше випадково. Тому в рамках технічного аудиту можна не закопуватися в це питання. Просто знайте, що дублів бути не повинно та якщо побачите їх – одразу пишіть правку програмісту. Сторінки, які мають бути проіндексовані – що мається на увазі? Дивимося на прикладі сайту PROSUVER. Є сторінки різного типу:

• Головна: https://prosuver.ua/
• Розділ: https://prosuver.ua/ blog/
• Стаття: https://prosuver.ua/ blog/seo/h1-h6/
• Сторінка: https://prosuver.ua/ contacts/

Розділів, сторінок і статей на сайті може бути багато. Наприклад, 10 сторінок, 400 статей і 20 розділів/підрозділів (цифри просто для прикладу). І все це, ми хочемо бачити в індексі ПС. Значить вони повинні бути включені в sitemap.xml. Але не перевіряти ж їх усі… Тому беремо по одній сторінці кожного типу, як у списку вище та через пошук шукаємо в sitemap. Знайшли? Все ок. Ні – пишемо програмісту сторінок якого типу не вистачає та просимо переробити карту.

Це була перевірка на потрібні сторінки. Що стосується непотрібних – на сайті можуть бути, наприклад, сторінки тегів (часто можна побачити після статті: #SEO, #Аудит) або ще якісь сторінки, які власник або ви закриваєте від індексації. Потрібно також узяти по 1 сторінці кожного типу (якщо їх кілька) і перевірити їхню наявність у карті. Їх там бути не повинно. Якщо є – пишемо правку.

Якщо поки не розумієте, що закрито від індексації – пропускаєте цей пункт. Вам все одно доведеться з цим розбиратися на іншому етапі. Коли розберетеся – перевірите ще раз.

404 помилка

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

Якщо відкриєте це посилання, побачите сторінку блогу з анонсами постів. А тепер уявіть, що хтось порекомендував блог Prosuver на форумі, але помилився в посиланні й написав «/blog8/». Випадково додав цифру або букву.

Інший приклад – ми самі робили посилання з однієї статті на іншу і помилилися під час введення url. Або у нас була на сайті стаття, ми її видалили, але посилання на неї залишилися як на нашому сайті, так і на інших майданчиках в інтернеті.

Питання – що має статися при спробі відкрити таку сторінку? А має статися дві речі:

1. Сервер має віддати відповідь – 404

І це перше, що потрібно перевірити. Гуглите будь-який «сервіс для перевірки відповіді сервера», вбиваєте неіснуючу адресу. Я для цього просто додав цифру 8 наприкінці, але краще замість /blog/, вставити щось подібне /hkajkja3jhhke8k/. І дивіться результат:

Якщо 404 – усе чудово, нічого робити не потрібно. Якщо 200 – пишете правку програмісту:

2. Сторінка 404 помилки повинна бути

Якщо ви відкриєте неіснуючу сторінку на цьому сайті, то побачите ось таке:

Тобто, створено спеціально відмальовану сторінку, щоб відвідувач розумів, що адреси, за якою він намагається перейти, не існує. І це правильно. Дизайн може бути будь-яким, але повідомлення про 404 помилку в тій чи іншій формі має бути. Якщо побачили щось подібне – все ок.

Але буває, що при спробі перейти за неіснуючою адресою відкривається головна сторінка сайту. При цьому в адресному рядку ви, як і раніше, бачите неіснуючий url, і він віддає 404 відповідь. Це може вводити в оману відвідувачів сайту. І вимагає коригування. У цьому разі пишемо в правки, що потрібно створити сторінку 404 помилки.

Швидкість завантаження

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

Чим перевіряти

Оскільки ця інструкція призначена для новачків, максимально все спростимо. Наберетеся досвіду, зможете опрацьовувати цей пункт більш детально. А поки що будемо використовувати тільки PageSpeed Insights. Переходите за посиланням, вставляєте адресу сторінки, що перевіряється, і натискаєте аналізувати.

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

Деякі перевіряють одну сторінку, частіше головну, і думають, що це показник для всього сайту. Це не так. Щоб отримати об’єктивну картину, потрібно перевірити по одній сторінці кожного типу. Наприклад: головна, розділ, товарна сторінка або послуга, стаття блогу (якщо є), просто сторінка (контакти, про нас і подібні). Разом 3-5 адрес.

На що дивитися

У результаті перевірки ви побачите:

Перша стрілка – це просто адреса сторінки, яку перевіряєте. А дивитеся ви на нижню стрілку (там де в мене цифра 100). Але зверніть увагу, що є вкладки – «Мобільний» та «Комп’ютер». Вам потрібно подивитися результат перевірки для обох вкладок. Тому що швидкість на мобільних і ПК може дуже сильно відрізнятися.

В якому випадку писати правку

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

• 90-100 балів (зелена зона) – усе відмінно.
• 50-89 балів (жовта зона) – нормальний результат, правка не обов’язкова, але рекомендуєте прискорити. Особливо, якщо цифра ближче до 50, а не до 80.
• 0-50 (червона зона) – пишете правку на прискорення.

На практиці найчастіше так – зелену зону ви не бачите майже ніколи. Червона не викликає питань – одразу відправляємо на прискорення і все. А ось із жовтою є нюанси. У разі потрапляння в цей діапазон, в ідеалі вам потрібно подивитися швидкість тих сайтів, з якими ви будете конкурувати в ТОП 10.

Бувають ситуації, коли у вас скажімо 60 балів, і чому б не прискоритися, але дивишся конкурентів, а ви за швидкістю завантаження найкращий. Тоді навіщо витрачати на це час зараз, якщо можна робити щось важливіше. А буває навпаки, у вас 75, боретеся за ТОП 3, а там сайти всі від 90 балів (рідко, але буває). Тоді потрібно підтягуватися до їхнього рівня.

Рекомендації в разі потрапляння в помаранчеву зону матимуть приблизно такий вигляд:

Canonical

Вище ми вже обговорили, що дзеркала – це копії сайтів і їх потрібно склеювати через 301 редирект. Крім копій сайту, можуть бути копії (дублі) сторінок усередині сайту. Боротися з ними можна різними способами. Один зі способів – прописати rel=«canonical».

Наприклад, є сторінка, яка доступна за 3 різними url-адресами. Якщо ви виберете одну з них за основну і потім пропишете на всіх 3 сторінках rel=«canonical» на «основну», тоді пошукові системи розумітимуть, що в результатах пошуку має бути тільки вона, а решта – це дублі, і ви це показуєте, а не намагаєтеся просунути всі 3 сторінки одразу.

Як перевірити

Встановлюєте розширення для Google Chrome – Seo Meta in 1 Click. Відкриваєте в браузері сторінки, що перевіряються. Також візьміть по 1 сторінці кожного типу. Потім натискаєте на значок розширення та дивитеся ось ці рядки:

Якщо навпроти url і canonical прописано адресу і вона збігається – все ок, правки не потрібні. Кожна сторінка і повинна мати канонікал на себе.

Якщо прописаний тільки url (він у будь-якому разі буде прописаний), а навпроти canonical нічого немає, пишете правку:

Якщо адреси не збігаються – потрібно розбирати чому. І залежно від цього писати правку. Причин може бути 2:

1. Ви перевірили дубль, а не основну сторінку. І тоді нічого робити не потрібно, найімовірніше там усе правильно. Але такого не буде, якщо ви просто взяли по 1 сторінці кожного типу. Дублі ще знайти потрібно…
2. На сайті можуть бути неправильно прописані canonical. Наприклад, для всіх сторінок сайту прописаний канонікал на головну сторінку. І тоді потрібна інша правка.

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

Мобільна версія

Практично всі клієнти, які у мене зараз у роботі мають відсоток трафіку з мобільних пристроїв понад 50%. А в деяких він перевищує 80%. При цьому SEO-фахівці-початківці, роблячи перевірку сайту на технічні помилки, часто дивляться тільки версію для ПК. Де працюють, там і дивляться… І це проблема. Мобільну версію перевіряти обов’язково!

Адаптивний сайт потрібно перевірити для різних роздільних здатностей екрана та різних браузерів. Для окремої мобільної версії потрібно додатково перевірити alternate, canonical, robots, xml-карту. Але стаття розрахована на новачків, тому робимо тільки простий аналіз, який часто ще й дуже ефективний.

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

• сайт взагалі адаптований чи ні;
• чи немає горизонтальної прокрутки;
• текст, написи на кнопках – чи все зручно читається;
• чи відбувається адаптація при повороті телефона горизонтально;
• телефони або кнопки месенджерів мають бути клікабельні.

Тут немає якихось суворих інструкцій з аналізу, все індивідуально, але сайт на мобільному телефоні має бути зручним та читабельним.

І другий момент – сайт на мобільному пристрої повинен мати ті самі блоки, тексти, кнопки, посилання та інші елементи, як і версія на ПК. Наприклад, якщо на ПК після цієї статті ви бачите блок «Схожі статті» з чотирма картками, то і на телефоні має бути так само.

Знайшли щось, що викликає питання – пишіть у правки, потім обговоріть із власником або програмістом. Тільки обов’язково додавайте скріншоти. В іншої людини може бути інший телефон і інший зовнішній вигляд…

Після цього повторюєте перевірку на тому ж пристрої, але в іншому браузері. Які браузери перевіряти? Найпростіший варіант – найбільш популярні (Chrome, Safari, Samsung). А якщо є доступ до аналітики, тоді краще подивитися, якими браузерами користується більша частина відвідувачів сайту та перевіряти на них. Потім берете планшет, якщо є під рукою, і повторюєте перевірку. Мало того, за можливості це потрібно зробити для пристроїв і на iOS, і на Android.

Hreflang

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

У чому проблема багатомовних сайтів

Дивимося на прикладі PROSUVER. На момент написання статті у сайту є українська та російська версії. Тобто, кожна сторінка представлена 2 мовами. Якщо просто зробити переклад, ПС може сприйняти ці сторінки як дублі. Щоб цього не було, потрібно «сказати» пошуковим системам, що це не дублі, а різні мовні версії. Для цього в HTML код сторінок потрібно додати спеціальний атрибут – hreflang.

Що таке hreflang

Це HTML-атрибут, який дає змогу показати пошуковим системам, що на сайті є кілька мовних версій сторінок. У коді сторінки має такий вигляд:

• link rel=«alternate» показує ПС, що є альтернативна версія сторінки;
• hreflang=«ru-UA» – вказує мову і регіон альтернативної версії;
• href=«https:// prosuver.ua/ru/» ­– її url-адреса.

Як перевіряти

Відкриваєте вихідний код сторінки. Через пошук знаходите «hreflang». Дивіться скільки таких рядків та що в них.

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

Друге – дивіться що прописано в лапках після hreflang. У нашому випадку – це «uk-UA» і «ru-UA». Українська та російська мови для України. Може бути написано так, а може:

• «uk» – українська мова, для всіх регіонів;
• «ru» – російська мова, для всіх регіонів.

Тобто вміст у цьому атрибуті може бути тільки із зазначення мови (малі літери), і тоді ПС має вважати, що регіон – увесь світ. Або через дефіс додається ще й позначення країни (великі літери), на аудиторію якої розрахована мовна версія. Це зроблено для випадків, коли робляться сторінки під різні країни, а мова у них збігається.

Ваше завдання – подивитися, які мови є на сайті і на які регіони він орієнтований. Після цього перевірити чи правильно вказані мови та регіони. Наприклад, якщо ви робите сторінки українською окремо під Україну і Польщу, там буде «uk-UA» та «uk-PL». Приклад правки:

Якщо щось пропустите, не проблема – пізніше під час перевірки парсером (до нього ми ще дійдемо нижче) ви побачите помилку. Тоді повернетеся до цього пункту та перевірите ще раз.

ЧПУ

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

У чому проблема

Якщо під час створення сайту не налаштувати ЧПУ, url-адреси формуватимуться автоматично. Вони можуть містити літери: цифри та символи (=, &, ?) і виглядатимуть приблизно так: https://site.com/?p=123. І це ще дуже простий варіант.

Такі адреси не дають розуміння про зміст сторінки. Що не дуже зручно для користувачів, особливо, коли вони діляться з кимось посиланням, і не вітається пошуковими системами. Більш високі позиції займають сайти з ЧПУ.

ЧПУ – це так звані людинозрозумілі URL. Це коли у нас для сторінки з мета-тегами в адресі буде «meta-tags» або «meta-tegi». Тобто, траслит латинськими літерами або переклад англійською. Приклад:

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

Як перевіряти

Якщо ЧПУ налаштовані – це видно на будь-якій внутрішній сторінці. Але краще відкрийте кілька сторінок різного типу і подивіться їхні url-адреси. Якщо там трансліт або переклад англійською – все ок. Якщо незрозуміло що, пишіть:

Це не стосується сторінок фільтрів на сайтах інтернет-магазинів. Там можуть бути нюанси. Але розділи, товари, послуги, статті – мають бути ЧПУ.

Favicon

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

Як робити перевірку:

• відкрили сайт у браузері – перевірили наявність фавікона на вкладці;
• додали в закладки – перевірили, чи з’явилася картинка поруч;
• загуглили назву сайту – перевірили результати пошуку.

Тут є тільки один момент – перевірити потрібно в різних браузерах та на різних пристроях. Якщо на якихось щось не відображається, тоді пишете правку:

Хлібні крихти

Якщо ви робите технічний SEO аналіз сайту, навряд чи є сенс пояснювати, що таке хлібні крихти. Але якщо раптом хтось не знає, тоді ось їхній приклад:

Перевірити їх дуже просто – відкриваєте кілька внутрішніх сторінок різного типу і дивитеся, чи є вони. На цьому перевірку закінчено. Питання в іншому – коли писати правку?

Ваше завдання – не просто перевірити, є хлібні крихти чи ні. Потрібно ще й зрозуміти, а чи є в них сенс. Хлібні крихти варто використовувати на сайтах з великим рівнем вкладеності сторінок:

• рівень вкладеності 4 і більше – вони точно потрібні;
• 3 – на розсуд власника ресурсу;
• 2 – не потрібні.

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

При цьому остання частина буде не активною або взагалі відсутня (налаштовують і так, і так). У підсумку за хлібними крихтами ви зможете повернутися тільки на головну. Сенсу від них ніякого. Якщо буде 3 рівні:

Вони не обов’язкові. Тому дивіться сайт – якщо власник їх зробив – ок, не зробив – можна порекомендувати, але написати, що це не обов’язково.

За більшого рівня вкладеності – потрібно рекомендувати як вкрай бажану правку.

Мікророзмітка

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

Мікророзмітка допомагає зробити сніпети більш привабливими. Наприклад:

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

Хочете, щоб були додані зірочки рейтингу, відгуки та ціни – потрібна мікророзмітка карток товарів.

Як перевіряти

Можна скористатися сервісом перевірки розширених результатів від Google:

Перевіряти будемо сторінки:

• https://prosuver.ua/contacts/ – щоб перевірити розмітку контактних даних;
• https://prosuver.ua/blog/seo/h1-h6/ – перевіримо розмітку статей.

Мікророзмітку хлібних крихт ми побачимо на обох цих сторінках. А товарної сторінки у нас немає. Якщо у вас інтернет-магазин – обов’язково додаємо і її. Це мінімальний набір. В ідеалі краще подивитися по одній сторінці кожного типу. Результат перевірки має такий вигляд:

Дивимося, яка розмітка присутня і чи є помилки. На нашому прикладі бачимо, що розмічено 2 елементи і помилок немає. Розмітка зроблена для статті та рядків навігації, що нам і було потрібно. Отже, все ок. Якщо її не буде, пишемо правку:

Натиснувши на «Статті» або «Рядки навігації», можна побачити детальну інформацію. Але зараз розбирати це не будемо. Проблема в тому, що напис «без помилок» не означає, що все добре. Наприклад, розмітка статті може бути присутня, а дата публікації в ній – ні, і виводитися в сніпеті вона не буде. Помилки для Google у такому разі немає, а сніпет не поліпшено. Але все це розберемо, коли будемо опрацьовувати сніпети. Зараз перевіряємо тільки наявність помилок або відсутність розмітки.

Заголовки H1-H6

Якщо не зовсім розумієте, що це таке і як із ними працювати – почніть із вивчення статті: «Заголовки h1-h6: що це таке і як їх використовувати, щоб бути кращими за 90% сайтів». Там усе детально розписано.

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

Ієрархія

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

Використання в навігаційних елементах

Про це я писав тут. Прочитайте, якщо не зрозуміло, про що йдеться. А потім дивіться на аналізований сайт. Якщо бачите, що назви якихось блоків, форм підписки, заголовки посилань на інші сторінки та інше загорнуті в теги h – пишіть програмісту правку на виправлення.

Дублі

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

Про які дублі йдеться – тільки про дублювання h1 на різних сторінках (дублювання h2-h6 не є проблемою). Тобто, теоретично не повинно бути двох сторінок, що мають однакові заголовки h1. Винятки, звісно, є, і потрібно підходити до цього хоча б із мінімальною увагою, а не просто копіювати дані з парсера. Наприклад:

Обидві сторінки мають заголовок «Блог». Але це не проблема, тому що це різні мовні версії. А ось якщо у вас різні товари матимуть однакові h1, ось це буде неправильно.

Зробити перевірку на дублі заголовків можуть різні програми та сервіси технічних аудитів сайту. Їх багато. У сьогоднішній статті я буду використовувати Neatpeak Spider. Ви можете вибрати будь-який інший.

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

Якщо дублі h1 є – дивіться що це за сторінки. Щось подібне до мого прикладу – ігноруєте. Дублюються назви товарів – пишете правку, що потрібно унікалізувати h1 для товарних сторінок. Рекомендуєте додати більше даних про товар (колір, розмір, артикул…), щоб зробити заголовки унікальними та такими, що більш точно описують товар.

Мета-теги

Для новачків спочатку рекомендую прочитати мої інструкції щодо:

• title;
• description;
• мета-тегів.

А вже потім приступати до перевірки. Ситуація тут така сама, як і з заголовками h1 у попередньому пункті – перевіряти мета-теги потрібно вже після оптимізації. Для перевірки використовуємо той самий парсер.

На що дивимося – порожній title або description та їхні дублі:

Якщо такі сторінки парсер знаходить після проведення робіт із внутрішньої оптимізації – потрібне доопрацювання. Тільки цього разу не програміста, а SEO-фахівця.

Також потрібно переглянути занадто короткі description і чи є питання щодо довжини title (часто буває занадто велика довжина). Якщо є – також дивимося що за сторінки та відправляємо їх на правку.

Посилання

Технічний аналіз сторінок сайту буде неповним без аналізу посилань. Тема досить обширна, особливо, якщо торкатися перелінковки та правильного розподілу ваги, тому поки що дивимося тільки найосновніше.

Биті посилання

Биті посилання – це коли у вас на сайті є посилання, що ведуть на неіснуючі сторінки. Якусь сторінку видалили, а посилання на неї залишилися. Їх теж потрібно видалити або змінити, щоб вони вели на наявні url-адреси.

Перевірити їх можна в тому ж парсері. Якщо такі є – там же дивитеся, на яких сторінках розташовані ці посилання, і пишете правку на їх видалення.

Циклічні посилання

Циклічне посилання – це посилання на ту саму сторінку, де воно розміщене. Список сторінок, які їх містять, ви так само знайдете в парсері (дивіться блок «Низька критичність»). Крім цього, можна просто подивитися сайт:

• Логотип у шапці сайту має бути посиланням на головну сторінку. Скрізь, крім найголовнішої сторінки.
• Якщо в підвалі є посилання, наприклад, на політику конфіденційності, то під час відкриття цієї сторінки, посилання має стати неактивним. Можете подивитися як це працює на цьому сайті.
• Те ж саме стосується посилань у меню під шапкою або в шапці.

Для того, щоб перевірити такі моменти, не потрібен ніякий парсер. Ним потім просто перевірите ще раз. У разі виявлення проблем, пишіть правку:

Зовнішні посилання

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

А зараз подивимося підвал/шапку сайту та сторінку контактів. Часто тут розташовуються кнопки соц. мереж, а іноді й посилання на якісь сайти. Усі вони мають бути прописані з використанням атрибута rel=«nofollow». Перевірити просто – відкриваєте вихідний код, шукаєте потрібні елементи і дивитеся, чи є там rel=«nofollow». Якщо ні – пишете в правки, що потрібно додати nofollow у такі-то посилання.

Дублі тексту та сторінок

Перші ви знайдете в парсері – вкладка «Дублікати тексту». Якщо такі є, тоді потрібна правка для SEO-фахівця:

Дублі сторінок ви знайдете в Google Search Console (доступ потрібно взяти у замовника) – Сторінки – Сторінка є копією. Канонічний варіант не обраний користувачем:

Шукати дублі, потрібно більш ретельно і не тільки тут. Але поки що хоча б це подивіться.

У цьому разі, за наявності дублів сторінок, їх потрібно позбутися. Закрити від індексації, прописати канонікал, налаштувати 301 редирект, видалити. Варіанти можуть бути різні, все залежить від того, що це за дублі та звідки вони беруться. Не розумієте, що робити – пишіть у правки, що потрібно позбутися дублів. А потім уже будете обговорювати.

Google Search Console

Як уже було написано вище – перед проведенням технічного SEO аудиту потрібно попросити у власника сайту доступ до Google Search Console. Якщо сайт ваш і він ще не доданий туди – додайте та почекайте кілька днів, поки дані зберуться, а вже потім робіть аудит.

Який він має вигляд – видно на скріні вище. Там є різні вкладки, які варто переглянути:

• Файли Sitemap – тут ви додаєте посилання на свою карту сайту.
• Рядки навігації – перевіряєте чи немає проблем із ними.
• Проблеми безпеки та чи немає на сайті фільтрів.

І ще багато всього. Вам у будь-якому разі потрібно пройтися по всіх вкладках та подивитися дані. Якщо будуть якісь проблеми – ви це побачите. Але насамперед дивіться «Індексування – Сторінки». Саме там буде найбільше інформації.

Як оформити технічний аудит

Чомусь у багатьох виникає більше запитань щодо оформлення, а не проведення аудиту. Тут важливо зрозуміти два моменти:

• Немає жодних правил оформлення.
• Писати потрібно так, щоб вас зрозуміли.

Тобто, від вас ніхто не чекає, що ви писатимете правки для програміста, ніби ви теж програміст та знаєте всю термінологію. Кожен має знати своє. І програмісту від вас потрібен не сленг і розуміння процесу, а чітко поставлене завдання, щоб він зрозумів, що від нього хочуть. Тому пишіть максимально просто та доступно, ніби намагаєтеся щось пояснити людині взагалі далекій від сайтів. Ви навіть не уявляєте, скільки питань це з вас зніме.

А щоб було ще простіше – подивіться на правки в статті, які обведені в рамки. Якщо ви зберете їх усі на одному аркуші. А зверху напишіть «ТЗ для програміста за результатами технічного аудиту сайту такого-то» – цього буде достатньо. Це і є ті 1-2 аркуші реально важливих рекомендацій. І жодної води.

Якщо ж замовник не знає, що ви перевіряли, а що ні, тоді міняйте назву на: «Технічний аудит сайту такого-то». Потім перерахуйте те, що ви перевірили, але де не було виявлено проблем і напишіть, приблизно так:

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

А нижче вставляєте правки. У такому разі замовник розумітиме, що перевірено, де є проблеми і що з цим робити. Ну а для тих, кому в аудиті важлива кількість аркушів, доведеться розписувати кожен пункт детально. Інформативніше він не стане, але для когось це може бути важливо.

Підіб’ємо підсумок

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