Індексованість, robots, sitemap і canonical

Модуль 5 · Урок 16

Індексованість, robots, sitemap і canonical

Robots.txt, noindex, sitemap і canonical вирішують різні задачі. Технічний SEO не додає всі сигнали «про всяк випадок», а будує несуперечливий контракт: що crawler може отримати, що дозволено індексувати й який URL є головним.

Crawl controlIndex controlCanonical signalsSitemap QA

Чотири інструменти — чотири ролі

ІнструментГоловна рольНе гарантує
robots.txtКерує crawling для user-agent і pathВидалення URL з індексу
meta robots / X-Robots-TagКерує indexing/serving після доступного fetchЕкономію crawl сам по собі
rel=canonicalСигналізує preferred representative для duplicate clusterАбсолютне виконання при конфліктах
sitemapДопомагає discovery і подає desired canonical URLsІндексацію або ranking

Robots.txt не є механізмом noindex

Disallow може зупинити crawling, але URL іноді лишається відомим через links і може з’явитися без snippet. Директива noindex у robots.txt не підтримується. Щоб Google побачив meta robots або X-Robots-Tag, сторінка/файл мають бути доступні для crawling.

Небезпечна комбінація

Disallow: /private-page + meta noindex може не дати crawler прочитати noindex. Для справді приватного контенту використовуйте authentication/access control; robots.txt публічний і не захищає дані.

Правила аналізуються для exact host, protocol і port. Перед зміною перевірте live robots URL, status, syntax, matched rule та вплив на CSS/JS/images, потрібні для rendering.

Meta robots і X-Robots-Tag

HTML-сторінки можуть отримати <meta name="robots" content="noindex,follow">; для PDF, images або server-level control зручний HTTP header X-Robots-Tag. Не використовуйте noindex для canonical alternate, яку хочете консолідувати: системі потрібен доступний індексований сигнал і одна послідовна стратегія.

Indexable content200, crawl allowed, без noindex, self/consistent canonical, корисний main content.
Excluded contentОбґрунтована причина: private/auth, removed, duplicate consolidation або low-value utility — не «економія» без evidence.

Canonicalization — узгодження сигналів

Google називає redirects і rel=canonical сильними signals, sitemap — слабшим. Найкращий контракт: internal links ведуть на preferred URL, sitemap містить його, alternate або redirect-иться, або має узгоджений canonical, а hreflang/structured data/metadata не суперечать.

Self-canonical. Унікальна indexable page посилається на точний preferred URL.
Duplicate alternate. Canonical веде на еквівалентну за змістом сторінку, не на випадковий hub.
Protocol/host/slash. Redirects, links і sitemap використовують одну норму.
Parameters. Рішення базується на функції URL і evidence, не на масовому pattern без review.

Sitemap як контрольована вибірка

Додавайте абсолютні canonical URLs, які повертають 200 та мають бути в Search. Розділяйте великі/різні типи контенту на sitemap files, щоб бачити coverage за групами. lastmod має відображати істотну зміну сторінки, а не час генерації файла.

Sitemap QA
Fetch 200 → valid XML/encoding → declared URLs belong to property → 200 final → indexable → canonical equals listed URL → no orphan/redirect/404 → lastmod trustworthy → submitted/monitored.

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

  1. Візьміть 10–20 дозволених URLs різних типів.
  2. Для кожного запишіть robots access, meta/X-Robots, status, declared canonical, sitemap membership та internal-link source.
  3. Позначте conflicts, але не виправляйте production без owner approval і бекапу.
  4. Сформулюйте preferred state та acceptance test для трьох найважливіших URL.

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

← НазадДалі →
Практична перевірка · урок 16 з 42

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

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

1. Що контролює robots.txt?
2. Чи підтримується noindex у robots.txt?
3. Чому Disallow + meta noindex може не спрацювати як задумано?