Оптимізація сайту: кроки для кращої продуктивності

Фактори, які мають найбільший вплив на ранжування сайту в пошукових системах, – це його продуктивність і працездатність. Це пов’язано з двома вкрай важливими причинами. По-перше, Google підтверджує, що продуктивність сервера впливає на частоту відвідувань і авторитетність сайту. По-друге, користувачі уникатимуть сайтів, які працюють повільно або некоректно, що призведе до зменшення переходів з органічної видачі. У гіршому випадку, це може призвести до “пого-стікінгу” – коли користувач повертається до результатів пошуку та обирає інший сайт.

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

Аудит серверних запитів потрібно робити з розрахунку наступних параметрів:

• відсутність серверних 500 помилок
• сервер використовує протокол https
• вчасно відповідає на запити
• коректне відображення сторінки
• корисні серверні помилки зручні для користувача (404 сторінка, та інші)
• сервер відображає однаковий зміст як для користувачів, так і для ботів

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

Використання HTTPS

HTTPS є стандартом для захищеного передавання інформації через Інтернет, таких запитів як, URL-адреси та вміст сторінок. Він забезпечує безпеку даних, що передаються між користувачами і сервером, шляхом шифрування даних, перевірки цілісності передавання та аутентифікації сервера, щоб переконатися, що він є дійсним. HTTPS став основним протоколом зв’язку, а використання менш безпечних протоколів, таких як HTTP, може призвести до покарання сайту.

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

Для швидкої оцінки використання HTTPS і наявність помилок, можна скористатися звітом GSC (категорія якість -> якість сторінок)

Тільки ті сторінки можуть вважатися зручними для користувачів, які використовують протокол HTTPS для передачі даних. Однак звіт про зручність сторінок не відображає, який протокол використовується для кожного URL. Замість цього показується тільки кількість сторінок, що використовують HTTP і HTTPS. Якщо на сайті занадто багато URL, які використовують протокол HTTP, ви побачите попереджувальний банер, а в розділі “HTTPS” буде показано статус сторінки з помилками.

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

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

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

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

Під час аудиту сайту необхідно перевіряти розмір сторінок і ресурсів, що завантажуються для їхнього створення, оскільки це може значно впливати на швидкість завантаження. Великі розміри сторінок можуть призвести до тривалих часів завантаження, що, своєю чергою, може негативно вплинути на досвід користувачів і ранжування сайту. Ресурси, такі як зображення, відео, PDF-файли, css, шрифти та JavaScript, можуть значно збільшити розмір сторінки. Одним зі способів оптимізації розміру сторінки є зменшення розмірів зображень та інших ресурсів шляхом стиснення.

Деякі показники швидкості сторінок можна побачити в GSC (Якість -> основні веб-показники).

Виявивши сторінки з великим розміром, їх можна зменшити внаслідок наступних кроків:

• сжати HTML
• мінімізувати JavaScript і CSS
• Зменшити розмір зображень
• Переглянути завантаження скриптів і по можливості відкласти їх

Кеш:

• використовувати кеш браузера
• використовувати CDN

Відповіді сервера:

• Покращити швидкість роботи сервера
• Зменшити кількість перенаправлень

Стан сторінок за статусом кодів

Щоразу, коли користувач запитує URL-адресу, сервер надсилає відповідь у вигляді статусу сторінки, який вказує на доступність вмісту для цієї адреси.

Наявність сторінок, яких немає (404), або помилки сервера (наприклад, 503), повідомляють пошуковим системам, що інформація, яку ви запитуєте на вашому сайті, може бути недоступною. Постійні помилки стану, які входять до серії 4xx і 5xx, можуть негативно вплинути на рейтинг сторінки.

Іноді коди стану, відмінні від 200 (“ok”), використовуються навмисно, наприклад, під час зміни URL сторінки та використання коду стану 301 для перенаправлення на новий URL. Коди 3xx надають важливу інформацію пошуковим системам про зміни на вашому сайті. Google підкреслює, що коди 3xx передають рейтинг сторінки на новий URL, який зрештою має замінити старий URL у результатах пошуку.

Звіти про індексацію сторінок у GSC включають інформацію про сторінки з помилковими кодами стану (Індексування -> Сторінки).

Аналіз редіректів

Постійне модифікування веб-сайту іноді може призвести до зациклювання 3xx кодів, де Сторінка А перенаправляється на Сторінку Б, яка, в свою чергу, перенаправляється на Сторінку С, і так далі. Google перестає відслідковувати перенаправлення після п’яти посилань, тоді як браузер зазвичай видає помилку після 20, хоча це число може змінюватись залежно від використовуваного браузера. У деяких випадках ці ланцюги (loop) можуть створювати незакінчені цикли, наприклад, коли Сторінка С перенаправляється не на Сторінку D, а назад на Сторінку Б, створюючи таким чином безкінечний цикл. Огляд веб-сайту, включаючи всі сторінки із статусом 3xx, дозволить виявити такі зациклювання редіректів.

Для того, щоб зрозуміти які сторінки переадресовуються, можна подивитися у звіті GSC ( Індексування -> Сторінки -> Сторінка з переспрямуванням)

Буває декілька типів редіректів. Поговоримо трохи детальніше про їхні типи та відмінності.

HTTP Redirects

HTTP-перенаправлення – процес автоматичного перенаправлення користувача з однієї веб-сторінки на іншу. Коли користувач запитує старий URL, сервер автоматично перенаправляє його на новий URL, де буде відображено відповідну веб-сторінку.

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

HTTP-коди 3xx виступають як інструкції для браузера користувача. Коди 3xx повідомляють браузеру, що запитуваний URL був перенаправлений і куди потрібно перейти для завантаження сторінки. Деякі найпоширеніші типи кодів 3xx, які використовуються сервером, включають в себе:

• 301: Переміщено назавжди
• 302: Тимчасово перенаправлено
• 303: Перенаправлено тимчасово
• 307: Тимчасово перенаправлено
• 308: Перенаправлення на постійній основі

Редіректи через мета тег refresh

Перенаправлення meta refresh відбуваються на рівні сторінки, що означає, що вони відбуваються на стороні клієнта, а не на сервері, на відміну від HTTP-перенаправлень. Однак, якщо необхідно зробити перенаправлення для SEO, краще використовувати HTTP-перенаправлення, а не за допомогою мета тега.

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

Однак, якщо ви не можете використовувати перенаправлення на стороні сервера, Google все-таки рекомендує використовувати перенаправлення за допомогою meta refresh. Проте, варто враховувати, що такі перенаправлення працюють повільніше і не передають всієї ваги сторінки.

Є два типи перенаправлення meta refresh:

Перший спрацьовує моментально після завантаження сторінки і позиціонується Google як постійний редірект:

<META HTTP-EQUIV="REFRESH" CONTENT="0; URL=HTTPS://WWW.EXAMPLE.COM/">.

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

<META HTTP-EQUIV="REFRESH" CONTENT="5; URL=HTTPS://WWW.EXAMPLE.COM/">

Редіректи на JavaScript

Перенаправлення за допомогою JavaScript також здійснюються на стороні клієнта, а не на стороні сервера. Однак, так само як і мета редіректи, вони не рекомендуються для SEO. Це пояснюється тим, що під час використання JavaScript-редіректів Google може неправильно проіндексувати ваші сторінки, що негативно позначиться на рейтингу вашого сайту в пошукових результатах.

Тести показують, що Google ставиться до JavaScript-редиректів так само, як і до 301-го редіректу. Однак, це не гарантовано, і використання цього типу перенаправлень може вплинути на авторитетність сторінки. Тому, для забезпечення найкращого SEO-результату, рекомендується використовувати перенаправлення на стороні сервера.

Приклад JavaScript-перенаправлення:

WINDOW.LOCATION.REPLACE("HTTPS://EXAMPLE.COM");

Використання редіректів і їх можливі наслідки.

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

Якщо ви перенаправляєте старий URL на нерелевантний URL, пошукові системи можуть не передати авторитет старої сторінки, що може призвести до soft 404. Це відбувається, коли сервер відправляє код стану “200 OK”, але Google вважає, що сторінка має бути 404. Така проблема може виникнути, якщо на новій сторінці немає контенту, і здається, що вона не пов’язана з перенаправленою сторінкою або на сторінці відображається повідомлення 404, але при цьому відправляється HTTP-статус 200.

Хоча soft 404 технічно не є кодом статусу, Google використовує його, щоб розуміти сенс сторінки. Справжні сторінки 404 Google пропускає, але помилки soft 404 краще уникати і виправляти всі наявні помилки.

Знайти soft 404 можна за допомогою GSC.

візьміть до уваги, що мова йде саме про “Помилка 404”, а не статус “Не знайдено (404)”

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

Уникнення ланцюжків перенаправлення

Ланцюжок перенаправлень виникає, коли URL перенаправляє користувача на інший URL, який, своєю чергою, перенаправляє на третій і т.д. Google може відстежити до 10 таких “стрибків”, але не варто ускладнювати ситуацію. Довгі ланцюжки можуть сповільнити сканування сайту, знижувати кількість посилань і збільшувати час завантаження сторінки, що негативно впливає на SEO та користувачів.

Щоб уникнути проблем, краще зробити перенаправлення одразу з URL A на URL C, минаючи URL B. Якщо ж виник цикл перенаправлення, коли один URL перенаправляє на інший, який перенаправляє назад на перший, це створює нескінченне коло, що призводить до заплутування користувачів та роботів. Щоб виправити цю проблему, потрібно вибрати “правильну” сторінку, на яку має бути зроблено редірект, і видалити інший редірект, що викликає цикл.

Уникайте посилань на сторінки з перенаправленнями

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

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

Щоб уникнути цієї ситуації, найкращим рішенням буде оновити всі внутрішні посилання на стару сторінку, замінивши їх на новий URL.

Перенаправлення для запобігання дублювання контенту

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

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

Однак, ви можете вирішити цю проблему, встановивши 301 перенаправлення з усіх варіантів сторінки на один URL. Це дасть змогу пошуковим системам знати, яку версію сайту слід індексувати.

Щоб уникнути дублювання контенту, можна використовувати перенаправлення в таких випадках:

• Сайт із і без префікса www
• HTTP і HTTPS протоколи
• URL з і без косої риски (/)
• URL з використанням великих і малих літер

Якщо це необхідно, слід перенаправити кожну дублюючу сторінку на бажану версію.