Топ-9 SEO-проблем і як їх уникнути або виправити

Що таке SEO-проблеми?

Потенційну SEO-проблему, що могла б нашкодити продуктивності наших сайтів у пошукових системах, можна було б ідентифікувати як проблему. Аби забезпечити адекватну оптимізацію сайтів, що високо ранжуються в Google (та інших пошукових системах), варто пам'ятати про кілька поширених помилок.

Зламані внутрішні та зовнішні посилання

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

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

Відвідувачі могли б сприйняти сторінку як недостойну довіри. Як ми знаємо, Google дійсно добре вміє ідентифікувати сприйняття користувачами сайту/сторінки. Тому, якщо користувачі незадоволені, відповідно пошукові системи теж будуть незадоволені.

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

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

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

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

Дубльований вміст

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

В результаті ми (як SEO-фахівці) можемо страждати від втрати трафіку або просто не отримувати повної користі від наших сайтів.

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

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

Аби уникнути цієї потенційної проблеми, нам треба мати правильні встановлені перенаправлення з http на https. Ми можемо легко це протестувати, набравши http://oursitename.com у браузері. Якщо наш протокол https увімкнено і правильно налаштовано, браузер має перенаправити нас на https://oursitename.com.

Так само, версія non-www сайту має перенаправляти на версію www, якщо це головна версія нашого сайту, і навпаки.

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

І все ж, це не те, про що варто хвилюватися, за умови, що ми впроваджуємо правильні canonical і атрибути no-index, коли це потрібно.

Примітка: теги canonical — популярний спосіб сказати Google, який набір подібних URL індексувати і вважати головним. Ще один спосіб — використовувати атрибут no-index, коли параметри спричиняють різні URL з однаковим чи подібним вмістом.

Невдачі тегу Title

Теги Title — серед найважливіших on-site SEO-елементів. Вони інформують пошукові системи про те, яка головна тема сторінки. Теги title також показуються в результатах пошуку вгорі кожного органічного списку. Це робить їх одним з ключових елементів і часто вирішальним фактором для користувачів, аби клацнути на конкретний результат.

Виділення часу на їхнє правильне налаштування — критичне SEO-завдання. Однак іноді цим нехтують, що призводить до низьких click-through rate.

Головні проблеми з тегами title такі:

• ›повна відсутність тегів title

У такому випадку Google встановить тег title на основі свого розуміння того, про що наша сторінка. Зазвичай він добре справляється з цим завданням, але все ж це пропущена SEO-можливість.

Добре встановлювати теги title самим, особливо для наших найважливіших сторінок.

• ›занадто довгі/короткі теги title

Використання коротких тегів title — пропущений спосіб залучити потенційних користувачів і змусити їх клацнути на наші результати. Звичайна практика — мати від 55-65 символів, що показуються у результатах пошуку.

І навпаки, теги title, що занадто довгі (понад 65 символів), можуть обрізатися і не показуватися повністю. Це створить ще одну пропущену можливість показати все наше повідомлення онлайн-світу.

Як ми бачимо тут, як title, так і meta description обрізані і відповідно не надають найкращого досвіду користувача.

• ›дубльовані теги title

Поширена практика для e-commerce-сайтів — мати ідентичні теги. Це часто стосується й інших типів сайтів, на жаль. Дубльовані теги title ускладнюють для вебсторінок виділення і відрізнення від інших подібних сторінок.

Проблеми з Robots.txt

Robots.txt — відносно простий, але корисний інструмент, що дає важливу інформацію та інструкції сканерам пошукових систем. Він розташований у кореневому каталозі сайтів і використовує формат plain text.

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

Надання доступу до staging- і dev-сайтів чи адмінпанелей

Існує кілька способів зупинити пошукові системи від досягнення будь-яких тестових і у розробці версій вашого домену. Один зі способів — використовувати команду у вашому файлі robots.txt, хоч є ефективніші способи це зробити (напр., HTTP authentication).

Однією з найпоширеніших інструкцій блокування для WP-сайтів є виключення папки wp-admin panel. Ось як це виглядає:

User-agent: * Disallow: /wp-admin/

User-agent: * означає, що інструкція застосовується до всіх ботів (Google bot, Bing bot тощо), а другий рядок каже, що ми хочемо зупинити їх від сканування папки /wp-admin/ і всього, що в ній.

Блокування важливих URL від сканування

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

User-agent: * Disallow: /example-important-directory/

Або іноді ми навіть можемо мати таке:

User-agent: * Disallow: /

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

Невключення посилання на файл sitemap

Robots.txt — чудовий спосіб полегшити пошуковим системам знаходження файлу sitemap сайту. Хоч це й не велика помилка, якщо ми її пропускаємо (особливо для менших сайтів), це все ж швидка і корисна річ.

Катастрофи з тегом Meta Robots

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

Існують різні випадки використання і конфігурації, але найпопулярніший (і часто небезпечний) — це тег noindex. Він «живе» у секції head HTML і виглядає так:

<meta name="robots" content="noindex,follow" />

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

• ›сторінки з thin content, що не надають реальної цінності користувачам- сторінки checkout на eCommerce-сайтах- URL, що містять чутливу інформацію- dev/staging-сторінки, не готові до запуску для публіки

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

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

Вам просто треба відкрити вихідний код і шукати (ctrl+f) команду «robots». Якщо помітите директиву «no index», то у вас проблеми! Хороша новина в тому, що ви тепер знаєте причину і як це легко виправити.

Canonical йде не так

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

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

З canonical ми просто кажемо пошуковим системам, яка є «головною» / «оригінальною» сторінкою, аби всі інші версії не створювали проблем. Більше того, Google знатиме, яку сторінку пріоритезувати і показувати в результатах пошуку.

Тут може виникати кілька проблем. Однією з них, як уже згадано, є відсутність встановленого canonical, коли у вас є різні URL з однаковим вмістом.

Якщо canonical встановлено, ось найпоширеніші небезпеки, про які треба пам'ятати:

• ›canonical URL вказує на URL з тегом noindex- canonical URL вказує на URL, що повертає код статусу 4xx чи 5xx- canonical URL вказує на небезпечну http-версію сторінки (коли у нас також доступна безпечна версія)- не самопосилаючий canonical (так званий canonical-ізований URL)

Примітка: це може бути нормально, якщо це навмисно, хоч у більшості випадків ми б хотіли самопосилаючі canonical

• ›тег canonical порожній чи вказує на невалідну сторінку

Проблеми з Hreflang

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

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

Наприклад, для іспанських відвідувачів ми хочемо надати версію /es сайту/сторінки, для німецьких відвідувачів — це має бути /de і так далі.

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

Анотації hreflang виглядають так:

<link rel="alternate" href="https://www.example.com/es/" hreflang="es" />

Найпоширеніші проблеми hreflang включають:

• ›відсутнє зворотне посилання

Альтернативні URL мають мати той самий код, що й сторінка, яка містить альтернативні URL hreflang. При використанні тегу hreflang і коли сторінка X посилається на сторінку Y, сторінка Y повинна посилатися назад на сторінку X. Базово, кожен рядок коду hreflang, що посилається на іншу сторінку, повинен мати той самий код на кожній сторінці, де його додано.

• ›виявлена мова не відповідає вказаній мові

Іноді мова, що вказана в тегах hreflang, відрізнятиметься від фактичного вмісту сторінки

• ›неправильні коди ISO

Популярна помилка — використання «en-UK» замість «en-GB» при таргетуванні англомовних відвідувачів у Сполученому Королівстві. Синтаксис теж дуже важливий. Хоч багато сайтів використовують підкреслення, аби вказати мови у своїх URL, лише дефіси працюють для hreflang.

• ›відсутність самопосилаючого тегу

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

• ›використання відносних URL замість абсолютних

Ще одна поширена помилка з hreflang. Ми маємо уникати відносних адрес, що надають лише шлях, і завжди обирати повний шлях сторінки.

Правильно:

<link rel="alternate" href="https://www.example.com/es/spanish-post" hreflang="es" />

Неправильно:

<link rel="alternate" href="es/spanish-post" hreflang="es" />

Ось один корисний інструмент для ідентифікації проблем hreflang - https://technicalseo.com/tools/hreflang/

Небезпеки JavaScript

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

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

Наприклад, погана реалізація JS може призвести до того, що Google не читає meta title і description, які ми налаштували, що потім створює проблеми з нашим CTR у результатах пошуку.

Саме тому критично важливо пам'ятати про інтерпретацію Google нашого JavaScript-вмісту і чи здатний він правильно сканувати та індексувати інформацію.

Проблеми з мобільною зручністю

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

Минуло кілька років відтоді, як Google перейшов на mobile-first indexing і бере мобільну версію вебсторінки до уваги з пріоритетом.

Однією з головних проблем, що частіше спостерігалися раніше, було показ різного вмісту користувачам desktop і mobile. Це дуже небезпечна практика і могла б призвести до нижчих органічних результатів.

Деякі з головних факторів, що могли б вплинути на продуктивність сайту, включають:

• ›велика кількість плагінів

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

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

• ›неоптимізовані зображення

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

• ›хостинг-сервіси

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

Підсумок

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

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

Успіху!