Перейти до вмісту

Як провести технічний аудит сайту

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

Можна подумати, що простіше було б сформувати документ з виправленням наявних помилок і додатковими покращеннями, заснованими на аналізі конкурентів і складеної стратегії On Page оптимізації.

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

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

Для чого проводиться технічний аудит

Як відомо, в ТОПах пошукової видачі знаходяться сайти які пошукові системи (далі “ПС”) вважають якісними. В технічному розумінні значно легше оцінити та зрозуміти як покращити свій сайт, оскільки вимоги ПС до технічного стану загально доступні.

Лише за рекомендаціями від Google, успішний проєкт створити не вийде, оскільки вони не розкривають повну картину оцінки сайту і дають доволі абстрактні вказівки

Якісна технічна оптимізація робить досвід взаємодії з вашим сайтом максимально комфортним як для користувача, так і для краулерів (так називаються роботи пошукових систем що сканують сайти). Виходить, що ми маємо двох суб’єктів для яких проводимо оптимізацію. Розглянемо хто на що впливає.

Робот:

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

Користувачі:

  • Клікають на сайт в пошуку (“+” до карми з боку пошукових систем)
  • Завдяки оптимізації, знаходяться на сайті тривалий час і не повертаються в пошук — сайт отримує “останній” клік.

Останній клік — це позитивний сигнал для пошукових систем, що сайт повність задовольнив пошуковий інтерес користувача і він не продовжив пошук

  • Роблять конверсії на сайті, в залежності від цілей (перегляд реклами, замовлення, залишення контактних даних тощо)

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

Чек-лист

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

Протокол https

Протокол https (Hypertext Transport Protocol Secure) потрібний, щоб захистити дані, які залишають користувачі. Ваш сайт має бути доступним лише за допомогою цього протоколу. Версії http та https не повинні існувати паралельно, щоб цього не було необхідно налаштувати склей за допомогою 301 редиректу. Якщо безпечного протоколу взагалі нема, то потрібно його отримати та налаштувати.

Google надає перевагу безпечним сайтам з налаштованим SSL (https) сертифікатом

Швидкість роботи сайту та CWV

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

Вже доволі тривалий час основною пошуковою вижачою є саме мобільна, тому оптимізація під мобільні девайси це один з головних факторів ранжування. Адаптацію можна перевірити хамірами груп показників CWV (Core Web Vitals) та перегладаючи мобільну версію в DevTool.

Перевірити можна за допомогою інструмента від Light House.

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

Коректність/наявність Robots.txt і Sitemap.xml

Файл robots.txt — текстовий документ із рекомендаціями для пошукових роботів: які сторінки можна сканувати, а які ні.

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

Приклад оптимізованого Robots.txt
Приклад оптимізованого Robots.txt

Для популярних CMS існують вже готові шаблони з урахуванням особливостей конкретних рушіїв сайтів.

Більше вимог та синтаксис можна знайти у довідці Google.

Файл Sitemap.xml — це файл із мапою вашого сайту. Пошукові боти сканують цей файл, щоб швидко зрозуміти структуру сайту. У sitemap.xml повинні бути лише ті сторінки, що мають 200 OK response code, канонічні та відкриті для індексації. Файл має знаходитися у корневій теці сайту на хостінгу.

Більше вимог і варіанти реалізації можна подивитися у довідці.

Щоб переглянути наявність/коректність, необхідно додати ввести в адресну строку до вашого домену /sitemap.xml.

Файли robots.txt та sitemap.xml допомагають роботам пошукових систем правильно сканувати сайт не витрачаючи ресурси на технічні сторінки

Коректність/наявність тегу canonical

Тег canonical використовується для відмічання “основних” сторінок. Такий тег допомагає уникати дублів. Якщо у вас на сайті є 2 схожі або такі, що дублюють одна одну, сторінки, то завдяки цьому тегу можна виділити основну. Це робиться додаванням в код <rel canonical = “ ”> з посиланням на обрану сторінку.

Цей тег має бути присутнім на всіх 200 OK сторінках. Основні та унікальні сторінки мають бути канонічні самі собі, тобто в тегу canonical мають містити посилання на себе.

Тег canonical допомагає ботам визначити цільові сторінки та уникнути сканування/індексації технічних дублів

Наявність битих посилань

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

Перевірити наявність таких сторінок можна за допомогою аналізаторів (Netpeak Spider, Screaming Frog, JetOctopus тощо).

Розповсюдженні типи битих посилань:

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

Биті посилання викликають негативний досвід у користувачів і являються негативним сигналом для пошукових систем

Наявність налаштованої 404 сторінки

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

Така сторінка має направляти користувача або на якісь категорії або на основну сторінку сайту. Наприклад:

Приклад налаштованої сторінки 404
Приклад налаштованої сторінки 404

Таку сторінку треба оформлювати в загальному стилі сайту.

Налаштована сторінка 404 допомагає не втрачати користувачів, які неправильно ввели адресу сайту

Склейка доменних імен

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

Спочатку треба обрати основну версію сайту, наприклад:

  • З www. або без
  • Зі слешем (/) вкінці адреси чи без

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

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

Склейка доменних імен дозволяє уникнути великої кількості дублів

Наявність та якість title та description

Title, description (назва та опис сторінки) – це елементи коду сторінки, які допомагають користувачеві та боту зрозуміти основну тему сторінки/сайту.

За допомогою тегів title та description формується сніпет (те, як ваш сайт виглядає у пошуковій видачі), його якість впливає на CTR (кількість кліків відносно кількості показів). Приклад оптимізованого сніпету:

Приклад оптимізованого сніпету
Приклад оптимізованого сніпету

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

Перевірити, чи всі сторінки мають прописані МЕТАдані та наявність дублів, можна за допомогою вже описаних аналізаторів.

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

Наявність дублікатів сторінок, контенту

Виявити технічні (коли одна сторінка доступна за різними URL) та повні (коли контент на різних сторінках повністю збігається) дублі можна за допомогою тих самих аналізаторів. Щоб позбавитися дублікатів треба:

  • Виділити основну сторінку (URL) з яким ви хочете працювати надалі;
  • Видалити або приховати (за допомогою редиректів, тегів canonical або Noindex) від роботів і користувачів сторінку що дублює основну.
  • Перевірити вміст сайту, щоби не було внутрішніх посилань на дубль.

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

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

Коректність верстки та HTML-коду

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

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

При організації верстки сторінок варто дотримуватися новітніх рекомендацій, зараз це HTML5. Якщо при розробці сайту використовувалися інші технології, то перевірити на наявність помилок можна за допомогою сервісу W3C. Необов’язково виправляти ВСЕ, що покаже аналізатор — приділяти увагу варто саме помилкам (Errors), попередження ж можна ігнорувати, якщо їхнє виправлення буде мати критичний вплив на функціонал сайту.

Чиста, оптимізована верстка сайту допомагає роботам пошукових систем краще розуміти контент на його сторінках

Структуровані дані

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

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

Найпоширеніші типи розміток:

  • Product (для сторінок товарів)
  • BreadCrumbs (для навігації “Хлібні крихти”)
  • Article/News (для блогових статей та новин)
  • Organization (для сторінки “Про нас”)
  • Local Bussines (для сторінки “Контакти” або для підвалу сайту)
  • FAQ (для блоку швидких відповідей)

Існує безліч типів структурованих даних, з якими ви можете ознайомитися на schema.org.

Приклад розширеного сніпету:

Приклад розширеного сніпету
Приклад розширеного сніпету

Розмітка структурованих даних дозволяє отримати розширений сніпет у видачі й краще донести до пошукових систем інтент і структуру сторінки

Оптимізація зображень на сайті

Зображення на сайті напряму впливають на швидкість роботи сайтів. Вважається, що картинки об’ємом понад 100 кб гальмують завантаження сторінок. Для оптимізації варто налаштувати автоматичне стиснення зображень та використовувати сучасні формати (.JPG, .WEBP тощо)

Окрім швидкодії сайту, зображення впливають на розуміння ваших сторінок роботами. Всі зображення можна оптимізувати, прописавши їм теги <Title> та <Alt>. Завдяки цим тегам ви можете зайвий раз посадити ключову фразу на вашу сторінку, допомогти пошуковим системам зрозуміти ваш контент і у випадку, якщо зображення не завантажиться, користувач побачить опис її змісту.

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

Внутрішня перелінковка

Під терміном “Внутрішня перелінковка” мається на увазі зв’язок різних сторінок сайту за допомогою внутрішніх посилань.

Зв’язок між сторінками за допомогою посилань необхідна не тільки для навігації, а й для передачі “внутрішньої ваги”. Вага — абстрактне поняття яка визначає пріоритетність та важливість сторінки. Вага має розподілятися по всьому сайту, щоб не виникало нульових відірваних сторінок (на них просто не будуть ходити боти пошукових систем).

Існують базові способи зв’язки сторінок між собою:

  • Обов’язкові елементи навігації — без них користувач не зможе потрапити на інші сторінки сайту, якщо йому це буде потрібно (скрізне меню в хедері сайту, бокове меню, хлібні крихти тощо);
  • “Корисні” посилання — елементи навігації яки не є обов’язковими, але можуть покращити досвід взаємодії користувача з вашим сайтом (блоки: “Схожі товари”, “Ви дивилися раніше”, “Останні статті” тощо);
  • Контекстні посилання — посилання залишені в вручну у тексті, частіше з анкором (текстом посилання), а не голий URL. Частіше в якості анкора виступають ключові фрази.

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

Загальні вимоги до автоматичних блоків посилань наступні:

  • Сторінки не мають посилатися самі на себе — це створює цикли та займає зайвий слот для більш корисного посилання. Також такі посилання “з’їдають” зайвий краулінговий бюджет, що буває критично, для великих сайтів;
  • Дві різні сторінки не мають мати взаємних посилань — це також утворює цикл;
  • Блоки перелінковки мають містити посилання лише на канонічні 200 ОК сторінки.

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

Для контекстних посилань всі ці правила також актуальні, лише додаються два нових:

  • Посилання має містити в собі анкор пов’язаний з цільовою сторінкою. Наприклад, якщо ми посилаємося на сторінку з продажу іграшок, то текст посилання має відповідати її інтенту;
  • Анкор має бути вписаний органічно і відповідати загальній темі статті/сторінки. Якщо в нас сторінка про бетонні вироби, то ставити в тексті лінк на продаж іграшок не варто.

Внутрішні посилання допомагають зв’язувати та розподіляти внутрішню вагу між усіма сторінками сайту. Такими лінками можна впливати на вагу окремих сторінок

Структура заголовків Н1-Н6

Н1-Н6 – це заголовки на сторінці. Вони мають бути розміщені в ієрархічному порядку та послідовно. H1 – головний заголовок H2 – підзаголовок і так далі.

Наявність на кожній сторінці заголовка H1 — обов’язкова. Всі інші рівні заголовків використовуються для того, щоб виокремити окремі частини сторінки/тексту так, щоб роботам і користувачам стало зрозуміло, про що буде йти мова в цій частині сторінки.

Важливо зберігати ієрархію — без H2 не може існувати H3, при тому H3 не може йти попереду першого заголовку H2. Найпопулярніша аналогія — заголовки та підзаголовки в книгах.

Наявність заголовків можна перевірити за допомогою інструментів парсерів. Ієрархію можна подивитися в коді типових сторінок, або використовуючі плагіни (для Chrome рекмендую SEO META in 1 CLICK).

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

Коректність налаштування мовних версій

Наявність різних мов на одному сайті це потужний інструмент для регіонального масштабування. Однак, для пошукових систем, важлива не тільки наявність, а й коректний зв’язок різних версій сайту. Зв’язок потрібен, щоб пошукові системи розуміли, що це не різні сторінки, які дублюють одна одну, а по факту одна й та сама, просто для різних мов та регіонів. При коректній

Загальні рекомендації треба дивитися безпосередньо у довідці Google. З усіх описаних там способів, найчастіше використовують тег <link rel=”alternate” hreflang=”lang_code”… >.

Часті помилки:

  • Стоять посилання не на всі мовні версії сторінки;
  • Посилання ведуть на редиректи, або на сторінки що не існують;

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

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

Формування зрозумілих URLs

Зрозумілі URLs це такі, що будуть зрозумілі (шок) людині та боту. Адреса сторінок має описувати про що сторінка і на якому розділі сайту користувач/бот знаходиться. Для формування URLs варто використовувати латиницю, а слова розділяти за допомогою дефісу “-”.

Приклад зрозумілої URL:  https://site.ua/ua/shop/mikrovolnovye-pechi/

Приклад неоптимізованого URL: https://site.ua/ua/shop/cat-112/

Пагінація

Пагінація або ж нумерація сторінок, використовується тоді, коли весь контент не вміщається на одній сторінці. Частіше це лістинги товарів/послуг або статей/новин.

Існують різні типи пагінації:

  • Генерація нових сторінок типу /?p=. Такий спосіб гарно підходить для SEO, оскільки так роботи ПС будуть ходити по всім сторінкам і товарам, які не вмістилися. Однак, такий спосіб може нагенерити багато дублів та інших технічних помилок, якщо невірно налаштувати;
  • Кнопка “показати більше”, що додає новий контент на відритій сторінці та нікуди не перенаправляє. Такий спосіб більш зручний для користувача, оскільки не змушує чекати поки відкриється нова сторінка. Також, так зручніше, якщо хочеться швидко порівняти товари з різних сторінок пагінації. Однак, роботи не зможуть знайти контент, який знаходиться на 2+ сторінках, через що він випаде з індексу.
  • Змішаний тип. Часто використовується саме на ECommerce сайтах, де зручність прямо впливає на прибуток. Суть в тому, що можна зробити як варіант для користувачів (показати більше), так і для роботів (окремі сторінки). Наприклад:
Приклад змішаного типу пагінації
Приклад змішаного типу пагінації

Правильно налаштована пагінація покращує користувацький досвід та покращує індексацію пошуковими системами

Кешування сайту

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

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

Перевірити кешування гуглом можна за допомогою оператору cache:

Наприклад: cache:http://site.com/blog

Бот аналізує текстову складову, то нам необхідно дивитися саме текстову версію:

Як перемкнутися на тексову версію кешу
Як перемкнутися на тексову версію кешу

Тепер ви можете побачити сторінку так, як її сканує бот пошукової системи.

Як виглядає текстовий кеш сторінки
Як виглядає текстовий кеш сторінки

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

Також, ви можете перевірити видимість контенту для ботів за допомогою Screaming Frog (або іншим веб краулером, що може аналізувати увесь вміст сторінки).

Найчастіше, для доступності контенту використовують технологію SSR. Про інші технології рендерингу можна почитати на порталі DOU.

Чек-лист — основа, а не обмеження

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

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

Варто зазначити, що робити технічний аудит треба періодично, на це є кілька причин:

  • Алгоритми пошукових систем періодично оновлюються, а з ними та вимоги ПС до сайтів;
  • SEO фахівці теж не стоять на місці й постійно знаходять нові закономірності та технології для покращення результатів в ранжуванні;
  • Сайти постійно оновлюються, як контентом, так і технічними нововведеннями, через що можуть з’являтися нові помилки — дублі, биті сторінки тощо;

Як висновок, можна додати лише одне:

Скільки сайт не оптимізуй — ідеальним він не стане.

Опубліковано вОптимізація