Модуль 4 · Урок 12

Як працює пошук: crawl, index, serve

SEO починається з правильної моделі системи. URL має бути знайдений, доступний для crawling, придатний до rendering та indexing, а потім — релевантним і корисним для конкретного запиту. Жоден етап не гарантує наступного.

DiscoveryCrawl + renderIndex + canonicalServe

Три етапи — різні питання

CrawlingЧи відомий URL, чи може Googlebot його отримати та чи не створює сервер перешкод?
IndexingЧи може система обробити основний контент, визначити дублікати й вибрати canonical?
ServingЧи відповідає проіндексований документ запиту, контексту й очікуваній якості?

Google прямо зазначає: навіть дотримання Search Essentials не гарантує crawling, indexing або показ. Тому професійний діагноз називає етап і доказ, а не робить висновок «Google не любить сайт».

Як URL стає відомим

Discovery відбувається через посилання з уже відомих сторінок, sitemap та інші сигнали. Sitemap допомагає повідомити про бажані canonical URL, але не є наказом про індексацію. Сторінка без внутрішнього посилання може залишатися orphan URL навіть тоді, коли існує в CMS.

СигналЩо перевіряємоТипова помилка
Internal linkСправжній <a href>, доступний шлях від hubНавігація лише через JS handler без crawlable href
Sitemap200 OK, canonical indexable URLs, актуальний lastmod404, redirects, noindex або випадкові parameter URLs
Server response200 для контенту, стабільність, відсутність auth wallSoft 404, 5xx, login або нескінченний redirect

Rendering — частина crawling pipeline

Googlebot використовує сучасний Chromium і запускає JavaScript, але rendering потребує ресурсів і часу. Критичний текст, посилання та metadata мають бути доступні у фінальному rendered HTML; заблокований JS/CSS, помилка API або контент лише після user action можуть змінити те, що бачить crawler.

View source недостатньо — screenshot теж недостатньо

Порівнюйте raw response, rendered DOM, HTTP status і URL Inspection. Людина може бачити сторінку, яку робот не отримує, або навпаки — красивий shell без основного змісту.

Indexing і canonical cluster

Після crawling Google аналізує текст, зображення, ключові теги й атрибути та групує схожі сторінки. Canonical — репрезентативний URL кластера; rel=canonical є сильним сигналом, але не абсолютною директивою. Якщо canonical, redirect, sitemap та internal links суперечать одне одному, система може обрати інший URL.

URL InspectionDeclared canonical, Google-selected canonical, crawl time, indexing state і rendered result.
Site evidenceHTTP response, robots, meta robots, canonical, internal links, sitemap і content uniqueness.

Serving: релевантність не купується

Проіндексована сторінка не зобов’язана з’являтися за кожним бажаним запитом. Serving враховує значення запиту, релевантність і якість контенту, usability та контекст користувача. Платіж Google не підвищує органічну позицію, а Ads не є shortcut до crawling чи ranking.

Діагностичний ланцюг
URL known? → fetch allowed? → HTTP/render correct? → indexable? → canonical consistent? → indexed? → relevant to query? → useful and competitive? → measured with correct limits?

Практика уроку

  1. Виберіть один власний або дозволений публічний URL.
  2. Зафіксуйте шлях discovery, HTTP status, robots, rendered content, canonical і sitemap presence.
  3. У Search Console, якщо маєте доступ, порівняйте declared та Google-selected canonical.
  4. Позначте кожен факт як crawl, render, index або serve evidence.
  5. Запишіть найменшу наступну перевірку, не змінюючи production без бекапу.

Офіційні джерела

Практична перевірка · урок 12 з 42

Закріпіть матеріал уроку

Три сценарні питання. Для зарахування уроку потрібно дати щонайменше дві правильні відповіді.

1. Які три основні етапи описує Google Search?
2. Що правильно про дотримання Search Essentials?
3. Яка роль sitemap?