Як змусити Google проіндексувати ваш сайт за допомогою звіту про висвітлення - Семальт знає відповідь



Пора глибоко заглибитися у ваш звіт про охоплення індексу Search Console, щоб зрозуміти, як ми можемо змусити Google швидше сканувати та індексувати ваш сайт. У Semalt у нас є кілька професійних технічних співробітників SEO, і всі вони знайомі з використанням звіту Google Index Console Index Coverage.

Якщо у вас є технічний SEO-експерт, який не користується або не розуміє цей інструмент, придбайте новий. Звіт GSCIC дав глибоке розуміння:
  • Які URL-адреси на вашому веб-сайті проскановано та проіндексовано Google, а які URL-адреси ще не проскановано.
  • Це також пояснює, чому пошукова система вибрала, яку URL-адресу вона сканує чи ні.
Звіт видається відносно простим, оскільки використовує колірну схему сигналів дорожнього руху для представлення своїх результатів.
  • Червоне світло (Помилка): Це показує, що сторінка не була проіндексована.
  • Жовтий (діє з попередженням): це вказує на те, що можуть виникнути деякі проблеми, які потребують виправлення. Якщо у вас є час, ви можете їх виправити. Однак вони не є критичними, і сторінка може бути проіндексована.
  • Зелений (дійсний): це означає, що все добре, і ваша сторінка проіндексована.
Іншим результатом є велика сіра зона, яка була виключена.

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

Проблеми із залученням SEO у звіті про охоплення індексів

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

Виявлений вміст наразі не індексується

Це трапляється тому, що URL-адреса відома Google за посиланнями або картою сайту XML, і вона знаходиться в черзі сканування. Проблема в тому, що Googlebot ще не сканує URL-адресу. Це вказує на те, що існує проблема з бюджетом сканування.

Як ми можемо це виправити? Якщо до цієї категорії входить лише кілька сторінок, ми можемо запустити сканування вручну, подавши URL-адреси в Google Search Console. Якщо існує значна кількість URL-адрес, ми витратимо більше часу на довгострокове виправлення архітектури вашого веб-сайту. Це включатиме таксономію сайту, структуру URL-адреси та структуру внутрішніх посилань. Це вирішить ваші проблеми сканування бюджету з їх джерел.

Проскановано - наразі не індексовано

Іноді Googlebot сканує URL-адресу і виявляє, що його вміст не вартий включення до її індексу. Це часто через проблеми, пов’язані з якістю, такі як застарілий вміст, тонкий або нерелевантний вміст, прохідні сторінки вхідних дверей або спам, створений користувачами. Якщо ваш вміст визнаний гідним, але він не проіндексований, існує ймовірність, що проблема в результаті рендерингу.

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

Припустимо, веб-сторінка не є корисною для вашого веб-сайту, 301 0r 410, URL-адреса. Якщо це важливо, змініть вміст сторінки та додайте тег без індексу, доки ви не вирішите проблему. Якщо у вас є URL-адреса, яка базується на моделі параметрів, ви можете зупинити сканування сторінки за допомогою деяких практичних методів обробки параметрів.
Коли вміст здається прийнятною якістю, перевірте, як він відображається без JavaScript. Google може індексувати вміст, створений за допомогою JavaScript, але це складніше, ніж індексування HTML. Це тому, що JavaScript має дві хвилі індексування. Перша хвиля індексує цю сторінку на основі початкового HTML-сервера, і ви можете побачити це, клацнувши правою кнопкою миші, щоб переглянути джерело сторінки.

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

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

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

Дубльований вміст без вибраного користувачем канонічного

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

Щоб це виправити, вам потрібно буде чітко позначити правильні каноніки. Переконайтеся, що ви використовуєте правильні теги rel=canonical для кожної URL-адреси, що сканується, на вашому веб-сайті. Це дає змогу зрозуміти, які сторінки Google вибирає як канонічні, нам потрібно буде перевірити URL-адресу в Search Console Google.

Дубльована, надіслана URL-адреса, яка не вибрана як канонічна

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

Щоб це виправити, вам доведеться позначити правильний канонічний за допомогою посилання rel=canonical. Це слід використовувати на кожній URL-адресі, що сканується, на вашому веб-сайті. Вам також слід переконатися, що ви включаєте лише канонічні сторінки у свою карту сайту XML.

Google вибирає інший канонічний

У цьому випадку ви розмістили свої посилання rel=canonical, але Google не вважає цю пропозицію прийнятною, тому вирішує індексувати іншу URL-адресу як канонічну.

Щоб це виправити, вам потрібно буде перевірити URL-адресу, щоб побачити канонічну URL-адресу, яку обрав Google. Якщо ви вважаєте, що Google зробив правильний вибір, змініть посилання rel=canonical. Якщо ні, вам доведеться попрацювати над архітектурою веб-сайту та зменшити кількість повторюваного вмісту. Ви також повинні надсилати сильніші рейтингові сигнали на сторінку, яку хочете бути канонічною.

Надіслану URL-адресу не знайдено (404)

Запит на сторінку не існує. Щоб це виправити, вам потрібно буде створити URL-адресу або повністю видалити її з вашої XML-карти сайту. Цю проблему легко уникнути, дотримуючись нашого посібника з файлу Sitemap XML.

Помилка переадресації

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

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

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

Помилка сервера (5xx)

Це відбувається, коли сервер повертає код відповіді 500 HTTP або внутрішній код помилки сервера, коли вони не можуть завантажити окремі сторінки. Це може бути спричинено різноманітними проблемами із сервером, але частіше за все це спричинене коротким відключенням сервера, яке перешкоджає ботам Google сканувати URL-адресу.

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

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

Висновок

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

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

mass gmail