▫️4 проблеми технічного SEO, які не знайде ваш софт

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

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

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

Розробники таких сервісів, як Screaming Frog або Ahrefs надають нам з вами велику послугу, продовжуючи вдосконалювати свої творіння. Вони допомагають SEO-фахівцям ефективніше аудіювати сайти і давати корисні поради клієнтам.

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

1. Петля канонічного редиректу.
2. Сторінки, зламані хакерами.
3. Визначення JavaScript-посилань.
4. Контент, прихований за JavaScript.

Чому софт не знаходить ці проблеми

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

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

SEO-інструменти, необхідні для виявлення цих проблем

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

Програма для веб-краулінгу

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

Для цього можна використовувати такий софт, як, наприклад:

• Screaming Frog;
• Sitebulb;
• OnCrawl;
• DeepCrawl.

Не так важливо, якому саме виробнику ви віддасте свою перевагу. Головне, щоб інструмент:

1. міг сканувати весь веб-сайт цілком, карту сайту і список URL-адрес;
2. мав можливість користувальницької настройки для пошуку і вилучення даних.

Google Search Console

Це само собою зрозуміло, але про всяк випадок варто відзначити. Вам буде необхідний доступ до Google Search Console, щоб провести технічний SEO-аудит. Для виявлення деяких проблем потрібні Історичні дані по проекту.

Проблема №1: петля канонічного редиректу

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

Чому це має значення

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

Таким чином, Google почне частіше переглядати веб-сторінку з 301-м перенаправленням, яка посилає Googlebot сигнал про петлю редиректу.

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

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

Як виявити петлі канонічного редиректу

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

1. Запустіть ваш улюблений софт для SEO-аудиту. Обов’язково проскануйте карту сайту, крім стандартного сканування краулером.
2. Перейдіть до звіту про canonical і експортуйте всі канонічні URL-адреси. Тільки не ті, які обійшов робот, а ті, що вказані в тезі canonical.
3. Запустіть нову перевірку за цими адресами і подивіться на коди відповідей. Всі URL – адреси повинні повертати код відповіді зі статусом 200.

Проблема № 2: сторінки, зламані хакерами

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

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

• Маніпулювання пошуком сайту. Це відбувається в тих випадках, коли сторінки результатів пошуку по сайту відкриті для індексації. Зловмисник ставить купу зворотних посилань на такі сторінки з нерелевантними запитами. Таке часто зустрічається в гемблінгу і фармі.
• Маніпулювання 301 редиректом. Це відбувається, коли хтось отримує доступ до сайту, створює на ньому сторінки з певної теми, і домагається їх індексації. Потім з таких сторінок робиться 301 редирект на сторонній сайт.
• Захоплення сайту. Це найпростіша атака. Хакер здійснює маніпуляції з кодом сайту і робить його непридатним для використання. Ну або, принаймні, псує індексацію.

Існують десятки видів злому сайтів, які можуть вплинути на SEO. Тут головне підтримувати належну безпеку проекту і регулярно (хоча б раз на тиждень) робити бекапи.

Чому це має значення

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

Як виявити зламані сторінки

На щастя, в нашому з вами арсеналі є не тільки інструменти, здатні запобігти або пом’якшити удар від злому, але і софт для пошуку проломів.

На жаль, більшість з подібних інструментів шукають тільки шкідливе ПЗ (malware). А деякі хакери вміють замітати сліди. Однак все одно є способи дізнатися, чи не був сайт зламаний в минулому.

Використовуйте Google Search Console

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

1. Перевірте облікові записи користувачів веб-сайту
2. Перегляньте всіх користувачів, які мають доступ в адмінку вашого сайту. Шукайте незнайомі облікові записи.
3. Перевірте журнал (лог) активності на сайті.
4. Переконайтеся, що у всіх облікових записів включена двофакторна авторизація.
5. Використовуйте спеціальні інструменти для онлайн-сканування
6. В інтернеті існує маса сервісів для сканування сайту на предмет наявності шкідливих програм. Але рідко який софт може визначити, чи був ваш сайт зламаний раніше.

Як варіант, можна використовувати інструмент “Have I Been Pwned?”. Він підкаже вам, чи були ваші адреси електронної пошти скомпрометовані витоком даних.

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

Проблема № 3: Визначення JavaScript-посилань

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

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

Чому це має значення

Googlebot не краулить JavaScript-посилання на веб-сторінках.

Як знаходити JavaScript-посилання на великих сайтах

Більшість SEO-інструментів не можуть виявити JS-посилання, за замовчуванням. Але в софт можна внести невеликі зміни, які вирішать дану проблему. Для цього потрібні спеціальні інструменти пошуку.

На жаль, браузери не відображають вихідний код в DOM, тому ми з вами не можемо шукати “onclick” або щось в цьому роді. Але, в якості альтернативи, є кілька поширених типів коду. Тільки не забудьте вручну перевірити, що це дійсно JS-посилання.

• <button>. Більшість розробників використовують тег кнопки для запуску подій JS. Не думайте, що всі кнопки є JS-посиланнями, але їх ідентифікація може допомогти зменшити проблему.
• data-source. “Джерело даних”. Підтягування файлу для використання коду при виконанні дії (начебто правильно написав, поправте мене в коментарях, якщо що). Часто використовується в JS-посиланнях.
  .js. Подібно атрибуту data-source, деякі HTML-теги тягнуть зовнішній файл JavaScript, щоб знайти вказівки для виконання дії.

Проблема № 4: вміст, прихований за JavaScript

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

Однією з кращих практик є поєднання хорошого контенту з хорошим UX. Але SEO при цьому страждати не повинно. І для таких проблем є обхідний шлях.

Чому це має значення

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

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

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

Щоб виявити прихований контент, досить перевірити DOM на веб-сторінці.

Для пошуку прихованого контенту:

1. Запустіть аудит за допомогою спеціального пошуку. Використовуйте маркери, які описувалися в проблемі з JS-посиланнями.
2. Перевірте кількість символів. Подивіться всі сторінки, на яких краулер виявив підозріло мало тексту.
3. Перевірте, чи відповідає це дійсності.

Інструмент не повинен замінювати фахівця

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

У міру виявлення таких незвичайних проблем, як описані вище в статті, додавайте їх в свій список (чек-лист) для SEO-аудиту, і не забувайте перевіряти в майбутньому.