Технічне SEO · Чекліст

Чекліст технічного SEO-аудиту сайту 2026: 42 перевірки, інструменти та критерії

Спочатку зафіксуйте baseline, потім збирайте докази для конкретних URL або шаблонів і закривайте проблему лише після повторення початкового тесту. У кожному пункті є інструмент, точний розділ, правило вибірки, критерій успіху та що саме зберегти.

Metricum LabОпубліковано21 серпня 2026 р.Оновлено23 серпня 2026 р.34 хв читання · 42 перевірок

Кожен висновок має спиратися на докази, а не на інтуїцію

Page indexing у Search Console використовуйте для пошуку патернів, а не як чергу “виправити всі Not indexed URL”. Очікувані редиректи, дублікати та видалені сторінки можуть бути коректними.
Технічна задача готова до реалізації, коли в ній є affected URL/template, observed state, expected state, owner, доказ і acceptance test.
Пороги Google використовуйте лише там, де Google їх публікує. Crawl depth, кількість inlinks і resource budgets — це евристики аудиту, а не ranking factors Google.
Звичайний crawlable HTML залишається базою для Search. Не створюйте паралельну Markdown- або llms.txt-копію контенту лише заради “AI SEO”.

Від виявлення URL до перевіреного виправлення

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

011. Зафіксуйте базовий стан до будь-яких змін1–5 022. Індексація: доведіть, які URL Google може й повинен індексувати6–11 033. Crawlability, robots.txt, sitemaps і доступність хоста12–16 044. HTTP status codes, redirects і canonical consistency17–23 055. Архітектура сайту та внутрішня перелінковка24–28 066. JavaScript rendering і parity контенту29–33 077. Core Web Vitals і browser-level performance34–38 088. Structured data, hreflang і фінальна перевірка39–42

Спочатку виправляйте те, що впливає на результат

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

P1Блокери5xx, випадковий noindex, блокування robots.txt, зламані canonical

P2Високий впливАрхітектура редиректів, orphan pages, проблеми рендерингу

P3ШвидкодіяCWV, розмір ресурсів і покращення на рівні шаблонів

P4CleanupНизькопріоритетні дублікати та технічна гігієна

Підготуйте ці інструменти до початку аудиту

Google Search Console

Індексація, URL Inspection, Crawl Stats і дані про органічну ефективність

Відкрити інструмент ↗

Screaming Frog SEO Spider

Raw- і JavaScript-crawl, аналіз status/canonical/internal links та за потреби дані GSC, GA4 і PageSpeed API в одному crawl

Відкрити інструмент ↗

Chrome DevTools

HTTP-заголовки, вкладка Network, відрендерений DOM і діагностика продуктивності

Відкрити інструмент ↗

PageSpeed Insights

Польові дані Core Web Vitals і лабораторна діагностика

Відкрити інструмент ↗

Google Rich Results Test

Перевірка структурованих даних

Відкрити інструмент ↗

Для кожної проблеми створюйте один готовий до впровадження рядок

Не передавайте розробникам презентацію лише зі скріншотами. Кожну проблему заносьте в backlog із чітким очікуваним станом, доказом, відповідальним і acceptance test.

Поле	Що вказати	Приклад
`URL / pattern`	Точний URL або однозначний шаблон URL	`/products/*`
`Issue ID`	Стабільний ідентифікатор для ticket і verification export	`IDX-07`
`Observed state`	Зафіксований стан із назвою інструмента та датою	GSC: noindex; 2026-08-21
`Expected state`	Результат, який можна перевірити, а не «виправити SEO»	200 + indexable + self-canonical
`Evidence`	Рядок export, скріншот, HAR або crawl-файл	`baseline/indexing.csv`
`Priority`	P1 blocker → P4 cleanup за матрицею вище	`P1`
`Owner`	Команда або функція, відповідальна за впровадження	Frontend / Platform / SEO
`Acceptance test`	Точна повторювана перевірка, після якої issue можна закрити	JS crawl + URL Inspection live test — pass

ІнструментGoogle Search Console

Точний шляхSearch Console → перемикач ресурсів → Settings → Ownership verification

Кроки

Переконайтеся, що працюєте з Domain property або root URL-prefix property. Для Crawl Stats потрібна коренева властивість.
Відкрийте Settings → Users and permissions і перевірте, що маєте роль Owner або Full user.
Запишіть точну назву ресурсу в таблицю аудиту, включно з протоколом для URL-prefix property.

Перевірку пройдено, якщо

Ресурс охоплює production-хост, який ви перевіряєте.
Page indexing та URL Inspection відкриваються без помилок доступу.

Доказ: Зробіть скриншот Settings → Ownership verification і запишіть точну назву ресурсу Search Console.

ДжерелоGoogle Search Console Help — URL Inspection tool · Google Search Console Help — Crawl Stats report

ІнструментGoogle Search Console

Точний шляхIndexing → Pages

Кроки

Відкрийте Indexing → Pages і використовуйте All known pages, якщо аудит навмисно не обмежений одним sitemap.
Зафіксуйте Indexed та Not indexed з датою аудиту, але не ставте “100% indexed” як KPI.
Відкрийте найбільші або бізнес-важливі reason rows. Візьміть sample URL за template і позначте expected / unexpected.
Page indexing report агрегований і може мати затримку. Для актуального стану одного URL використовуйте URL Inspection.
Збережіть YYYY-MM-DD_gsc_page-indexing.csv і не перезаписуйте baseline після виправлень.

Перевірку пройдено, якщо

Збережені dated totals, reason-level samples і template classifications.
Expected exclusions задокументовані; для unexpected spikes або важливих affected templates призначено owner.

Експортувати / зберегти: Експортуйте таблиці ключових причин і збережіть оригінальні CSV без редагування.

ДжерелоGoogle Search Console Help — Page indexing report · Google Search Off the Record — How to read the Indexing Report

ІнструментGoogle Search Console

Точний шляхPerformance → Search results → Pages

Кроки

Для свіжих змін використовуйте, наприклад, Last 28 days vs Previous 28 days; для низького трафіку — 3 months vs previous period.
На вкладці Pages експортуйте clicks, impressions, CTR та average position.
Позначте сторінки з найбільшими impressions і бізнес-цінністю. Вони стануть обов’язковою вибіркою для всіх наступних перевірок.

Перевірку пройдено, якщо

Є датований export landing pages.
Priority URLs визначені до початку crawl-а.

Експортувати / зберегти: Експортуйте CSV/Google Sheets; колонку Priority додавайте в копії, а не в raw export.

ДжерелоGoogle Search Central — In-depth guide to how Google Search works

ІнструментScreaming Frog + sitemap + Search Console

Точний шляхSEO Spider → Mode: Spider; окремо завантажте XML sitemaps

Кроки

Завантажте всі production XML sitemap, вказані в robots.txt і Search Console.
Запустіть звичайний crawl від canonical homepage з увімкненими внутрішніми hyperlinks.
Об’єднайте sitemap URLs, crawler Internal HTML, GSC Pages та список revenue/conversion landing pages.
Не затирайте оригінальні URL нормалізацією: окрема raw-колонка потрібна, щоб бачити різницю case, slash і parameters.

Перевірку пройдено, якщо

У master inventory є всі бізнес-критичні сторінки.
URL, знайдені тільки в GSC/sitemap/analytics, позначені як потенційні orphan pages.

Експортувати / зберегти: Створіть master-urls.csv: Source, URL, Priority, Expected indexable?, Notes.

ДжерелоGoogle Search Central — Build and submit a sitemap · Screaming Frog — SEO Spider configuration

ІнструментScreaming Frog SEO Spider

Точний шляхConfiguration → Spider → Rendering

Кроки

Crawl A: Rendering = Text Only. Збережіть project file.
Crawl B: Rendering = JavaScript з тим самим start URL, crawl scope, limits і user-agent assumptions.
У Configuration → Spider → Extraction увімкніть Store HTML / Store Rendered HTML для порівняння original і rendered output.
Опційно підключіть Google Search Console, Google Analytics 4 і PageSpeed Insights через Configuration → API Access, якщо доступи є.
Тримайте експорти окремо та додайте Rendering = raw або js у робочі таблиці.

Перевірку пройдено, якщо

Обидва crawls мають еквівалентний scope/configuration, окрім rendering.
Різницю в content, links, canonicals, titles і status handling можна прив’язати до конкретних URL або templates.

Експортувати / зберегти: Збережіть обидва project files, Internal HTML та JavaScript-tab exports.

ДжерелоScreaming Frog — SEO Spider configuration · Screaming Frog — How to crawl JavaScript websites · Google Search Central — Understand JavaScript SEO basics

ІнструментMaster URL inventory + Search Console

Точний шляхMaster inventory → Expected indexable?; Search Console → Indexing → Pages

Кроки

Порахуйте лише URL, які мають бути canonical search landing pages.
Порівняйте з Indexed у Search Console і далі аналізуйте по template, а не вимагайте ідеальної 1:1 відповідності.
Створіть gap-list expected-indexable URL, які потрапили в Not indexed.

Перевірку пройдено, якщо

У кожного critical expected-indexable URL відомий indexation state.
Duplicates та навмисно noindexed URLs не включені в target count.

ДжерелоGoogle Search Console Help — Page indexing report

ІнструментGoogle Search Console

Точний шляхIndexing → Pages → Why pages aren’t indexed → оберіть reason

Кроки

Пріоритезуйте unexpected growth, великі reason groups і будь-які reasons з бізнес-важливими URL.
Перевірте щонайменше 5 URL на reason і template як робоче правило аудиту, а не вимогу Google. Якщо результати змішані — збільшіть sample.
Класифікуйте кожен sample: Expected exclusion / Technical defect / Content or duplication / Needs deeper inspection.
Не використовуйте “Crawled - currently not indexed” як готовий technical root cause. Перевірте цінність content, canonical-сигналів, internal links і ширший pattern по сайту.

Перевірку пройдено, якщо

Кожен великий reason має класифікацію та sample URLs.
Жоден business-critical URL не залишився у незрозумілому exclusion bucket.

Експортувати / зберегти: Додайте Reason, Template, Expected?, Root cause, Owner у backlog.

ДжерелоGoogle Search Console Help — Page indexing report · Google Search Off the Record — How to read the Indexing Report

ІнструментGoogle Search Console

Точний шляхВставте повний URL у верхній рядок → Page indexing → Test live URL

Кроки

Спочатку запишіть Last crawl, Crawled as, Crawl allowed, Indexing allowed та Google-selected canonical з indexed version.
Натисніть Test live URL і порівняйте current fetch/indexability.
За можливості відкрийте View crawled page та перевірте HTML, який отримав Google.
У backlog зазначте: дефект є в indexed snapshot, live version або в обох.

Перевірку пройдено, якщо

Для priority URLs є докази indexed і live state.
Зафіксовано Google-selected canonical, де він доступний.

Доказ: Зберігайте підсумковий статус разом із полями canonical та crawl, на яких він ґрунтується.

ДжерелоGoogle Search Console Help — URL Inspection tool

ІнструментScreaming Frog + Chrome DevTools

Точний шляхSEO Spider → Directives; DevTools → Network → document → Headers

Кроки

Експортуйте всі noindex URL з Directives tab.
Для priority URL перевірте і <meta name="robots"> у HTML, і X-Robots-Tag у response headers.
Знайдіть noindex URL, які одночасно blocked by robots.txt.
Порівняйте noindex list із sitemap: indexable sitemap URLs не повинні бути noindex.

Перевірку пройдено, якщо

Немає noindex на priority canonical URLs.
Intentional noindex URLs залишаються crawlable, якщо немає окремої причини блокувати crawl.

Експортувати / зберегти: Export Directives → noindex і join із sitemap inventory.

ДжерелоGoogle Search Central — Block Search indexing with noindex

ІнструментSearch Console + DevTools

Точний шляхIndexing → Pages → Soft 404; DevTools → Network → document → Status

Кроки

Відкрийте кожен reported template і подивіться, що реально бачить користувач.
Якщо контент видалено назавжди і заміни немає — повертайте HTTP 404 або 410.
Якщо є конкретна заміна — permanent server-side redirect саме на неї, а не на homepage.
Для SPA перевірте випадковий invalid route: server не повинен віддавати generic 200 app shell для неіснуючої сторінки.

Перевірку пройдено, якщо

Неіснуючі URL повертають 404/410 або конкретний виправданий redirect.
Valid pages не рендеряться як blank/near-blank для Googlebot.

Перевірка після виправлення: Після deploy повторіть URL Inspection і перевірте HTTP behavior.

ДжерелоGoogle Search Central — Troubleshoot crawling errors and soft 404s · Google Search Central — Fix Search-related JavaScript problems

ІнструментGoogle Search Console + crawler

Точний шляхURL Inspection → Page indexing → Google-selected canonical

Кроки

Запишіть User-declared canonical і Google-selected canonical для кожного priority mismatch.
Перевірте, що preferred canonical повертає 200, indexable, має internal links і є в sitemap.
Для duplicate variants перевірте redirects, canonical tags і схожість main content.
Спочатку усуньте конфлікт signals, тільки потім request indexing.

Перевірку пройдено, якщо

Priority pages або self-canonical і обрані Google, або alternate canonical є навмисним і задокументованим.

ДжерелоGoogle Search Central — How to specify a canonical URL · Google Search Console Help — URL Inspection tool

ІнструментBrowser + curl + Search Console

Точний шляхВідкрийте https://example.com/robots.txt; за потреби Search Console → Settings → robots.txt report

Кроки

Запитайте /robots.txt на кожному production host із crawlable content.
Файл має бути plain text у root, без authentication і redirect loops.
Виконайте curl -I https://example.com/robots.txt і зафіксуйте HTTP response.
Перевірте, що Sitemap: directives містять absolute production URLs.

Перевірку пройдено, якщо

robots.txt стабільно доступний і відповідає production environment.
На production немає staging-правила Disallow: /.

Доказ: Збережіть копію production robots.txt у папці з доказами аудиту.

ДжерелоGoogle Search Central — Introduction to robots.txt · Google Crawling Infrastructure — Update your robots.txt file

Інструментrobots.txt + URL Inspection + crawler

Точний шляхrobots.txt; URL Inspection → Crawl allowed?

Кроки

Випишіть Disallow, які можуть match HTML, CSS, JavaScript або API для indexable pages.
Для кожного широкого правила перевірте мінімум 3 URL: intended block, edge case і URL, що точно має crawl-итися.
У URL Inspection для priority pages перевірте Crawl allowed? = Yes.
Не використовуйте robots.txt для приховування sensitive content — потрібен access control/authentication.

Перевірку пройдено, якщо

Жоден indexable template або critical rendering resource не blocked випадково.
Кожен blocked URL має документовану crawl-причину.

ДжерелоGoogle Search Central — Introduction to robots.txt · Google Search Console Help — URL Inspection tool

ІнструментBrowser + Search Console + crawler

Точний шляхSearch Console → Indexing → Sitemaps; відкрийте sitemap URL

Кроки

Кожен submitted sitemap повинен повертати 200 і valid XML.
Порахуйте URL і uncompressed file size.
Офіційний максимум Google для одного sitemap: 50 000 URLs або 50 MB uncompressed. Розділіть файл до перевищення будь-якого ліміту.
Для sitemap index перевірте кожен child sitemap: production, current, reachable.

Перевірку пройдено, якщо

Кожен sitemap ≤50 000 URLs і ≤50 MB uncompressed.
Search Console показує successful processing.

Експортувати / зберегти: Збережіть sitemap URL, URL count, file size, lastmod coverage, GSC status.

ДжерелоGoogle Search Central — Build and submit a sitemap

ІнструментScreaming Frog + sitemap export

Точний шляхSEO Spider → Response Codes / Canonicals; join із sitemap URL list

Кроки

З’єднайте sitemap URL зі status code, indexability і canonical target.
Flag: 3xx, 4xx, 5xx, noindex, robots block або canonical на інший URL.
Приберіть такі URL із generated sitemap або виправте сторінку, якщо вона має бути canonical.
Переконайтеся, що нові canonical URLs автоматично додаються після publication.

Перевірку пройдено, якщо

За робочим критерієм аудиту 100% URL, поданих у sitemap, мають бути URL, які ви справді плануєте індексувати як canonical.
Немає known redirect/error/noindex/alternate-canonical URL.

Експортувати / зберегти: sitemap-quality.csv: URL, Status, Indexability, Canonical, Issue.

ДжерелоGoogle Search Central — Build and submit a sitemap · Google Search Central — How to specify a canonical URL

ІнструментGoogle Search Console

Точний шляхSettings → Crawl stats → Host status / Crawl requests / Average response time

Кроки

Перевірте, чи Host status не показує recent significant availability issues.
У Crawl responses перегляньте 5xx, DNS, robots.txt unavailable і redirect-loop patterns.
Порівняйте Average response time spikes з deploys/incidents і падінням crawl requests.
Crawl Stats — advanced report; найбільш корисний для великих сайтів і root-level properties.

Перевірку пройдено, якщо

Немає unexplained host-availability incident у важливі crawl periods.
5xx/network-error spikes мають owner і remediation.

Експортувати / зберегти: Зафіксуйте incident date, response category, host, engineering ticket.

ДжерелоGoogle Search Console Help — Crawl Stats report

ІнструментScreaming Frog SEO Spider

Точний шляхResponse Codes → filters 2xx / 3xx / 4xx / 5xx

Кроки

Експортуйте internal URLs для кожного non-2xx status class і додайте source/inlink data, щоб було видно page/template, який створює problem URL.
404/410 класифікуйте як Expected gone / Broken internal link / Valuable legacy URL / Needs redirect.
Не робіть mass redirect нерелевантних 404 на homepage. Якщо старий URL має clicks, impressions, backlinks або чітку replacement page — відновіть його або поставте permanent redirect на найближчий еквівалент.
Unexplained 5xx на crawlable production URLs оформлюйте як engineering incident із affected scope і time window.

Перевірку пройдено, якщо

Кожен recurring non-2xx pattern має intended state та owner.
Broken internal links виправлені у source; valuable legacy URLs мають рішення restore/redirect; expected 404/410 залишаються навмисно видаленими.

Експортувати / зберегти: Bulk Export → Response Codes → Client Error (4xx) Inlinks / Server Error (5xx) Inlinks.

ДжерелоGoogle Search Central — Redirects and Google Search · Google Search Central — Troubleshoot crawling errors and soft 404s · Google Search Central — How to perform a technical SEO audit

ІнструментScreaming Frog SEO Spider

Точний шляхReports → Redirects → Redirect Chains або equivalent export

Кроки

Експортуйте chains і відсортуйте за hop count.
Змініть internal links, canonicals, hreflang і sitemap так, щоб вони вели прямо на кінцевий URL зі статусом 200.
Legacy redirects для external entry points можна залишити, але internal hops — прибрати.
Для звичайної internal navigation використовуйте target ≤1 redirect hop; exceptions документуйте.

Перевірку пройдено, якщо

Internal links ведуть на final canonical URL або мають максимум один виправданий hop.

Експортувати / зберегти: Передайте engineering: Source URL → Current target → Final target → Hop count.

ДжерелоGoogle Search Central — Redirects and Google Search

Інструментcurl + browser + crawler

Точний шляхПеревірте http/https, www/non-www для homepage і deep URL

Кроки

Запитайте всі технічно можливі variants.
Кожен non-preferred variant має permanent redirect на exact preferred equivalent URL.
Не redirect-те всі старі deep URLs на homepage, якщо існує точна заміна.
Internal links мають одразу використовувати preferred version.

Перевірку пройдено, якщо

Лише один host/protocol version повертає 200 для canonical pages.
Інші variants permanent-redirect на equivalent preferred URL.

ДжерелоGoogle Search Central — Redirects and Google Search · Google Search Central — How to specify a canonical URL

ІнструментCrawler + server tests

Точний шляхSEO Spider → URL / Canonicals; manual URL variants

Кроки

Перевірте /page і /page/, якщо stack може віддавати обидва.
Перевірте uppercase/lowercase path variants.
Перевірте utm_*, sort, filter, session IDs та інші parameters.
Оберіть canonical format і синхронізуйте internal links, sitemap, canonical tags та redirects.

Перевірку пройдено, якщо

Внутрішньо використовується один preferred URL format.
Duplicate variants redirect/canonicalize правильно або навмисно відрізняються.

ДжерелоGoogle Search Central — How to specify a canonical URL

ІнструментScreaming Frog SEO Spider

Точний шляхCanonicals → Missing / Multiple / Non-indexable Canonical

Кроки

Експортуйте indexable HTML URLs без canonical.
Експортуйте multiple/conflicting canonical elements.
Для canonical pages canonical має бути absolute, preferred host/protocol і відповідати normalized URL.
Для duplicates задокументуйте причину canonical на іншу сторінку.

Перевірку пройдено, якщо

Кожна intended canonical HTML page має один clear canonical target.
Немає conflicting canonical-сигналів.

Експортувати / зберегти: Групуйте Canonicals issues за template.

ДжерелоGoogle Search Central — How to specify a canonical URL

ІнструментScreaming Frog SEO Spider

Точний шляхCanonicals → Canonical Link Element 1; join target to status/indexability

Кроки

Витягніть unique canonical targets.
Crawl target URLs і join HTTP status, robots, indexability.
Flag targets, які redirect, error, noindex або robots blocked.
Якщо дефект масовий — виправляйте template, а не URL по одному.

Перевірку пройдено, якщо

У canonical targets немає contradictory directives або invalid responses.

ДжерелоGoogle Search Central — How to specify a canonical URL · Google Search Central — Block Search indexing with noindex

ІнструментMaster URL inventory

Точний шляхJoin final URL, redirect, canonical, sitemap flag, internal inlinks

Кроки

Для кожної duplicate URL family визначте один Preferred URL.
Permanent redirects мають вести на нього, де це доречно.
rel=canonical, sitemap і internal links мають підтримувати той самий URL.
Створіть Conflict flag, якщо будь-який signal вказує на іншу адресу.

Перевірку пройдено, якщо

Для priority URL families усі controllable signals підтримують один preferred URL.

Експортувати / зберегти: Variant → Redirect → Canonical → Sitemap → Internal link target.

ДжерелоGoogle Search Central — How to specify a canonical URL

ІнструментChrome DevTools + crawler

Точний шляхDevTools → Elements; SEO Spider → Inlinks

Кроки

Перевірте primary navigation, cards, pagination і load-more paths у Elements.
SEO-critical destination має бути реальним <a href="…">, навіть якщо JS також обробляє click.
У raw crawl перевірте, чи important paths discoverable без JS там, де це можливо.
Flag buttons/divs із click handler, які замінюють crawlable navigation.

Перевірку пройдено, якщо

Кожен SEO-critical navigation path має href або інший навмисний discoverability mechanism.

ДжерелоGoogle Search Central — SEO link best practices for Google · Google Search Central — Understand JavaScript SEO basics

ІнструментScreaming Frog + master inventory

Точний шляхCrawl → Inlinks; merge із sitemap/GSC URLs

Кроки

З’єднайте master URL inventory з Unique Inlinks із crawler.
Expected-indexable URL з 0 crawlable internal inlinks вважайте orphan.
Для priority pages використовуйте <3 unique internal inlinks як review trigger, а не правило Google. Перед додаванням links оцініть їхню контекстність і релевантність.
Додавайте contextual links із релевантних hubs/supporting pages замість перенесення всіх URL у global navigation.

Перевірку пройдено, якщо

Жодна important indexable page не має 0 crawlable internal inlinks.
Priority pages з <3 unique inlinks мають documented reason або contextual-link action.

Експортувати / зберегти: orphan-pages.csv: URL, Source found, Inlinks, Suggested hub, Owner.

ДжерелоGoogle Search Central — SEO link best practices for Google · Google Search Console Help — Page indexing report · Screaming Frog — Internal Linking Audit With the SEO Spider

ІнструментScreaming Frog SEO Spider

Точний шляхInternal → Links → Crawl Depth

Кроки

Відфільтруйте priority indexable HTML і відсортуйте Crawl Depth за спаданням.
Позначте priority URLs глибше ніж 3 clicks для review. Це architecture heuristic, а не ліміт Google.
Пройдіть реальний click path і знайдіть missing hub links, надмірну taxonomy nesting, faceted paths або URLs, що лінкуються лише з low-value templates.
Коли IA дозволяє, побудуйте релевантний contextual path, який тримає важливі сторінки приблизно в межах 1–3 clicks від major hub.

Перевірку пройдено, якщо

Priority pages досяжні в межах documented 1–3-click working target або мають обґрунтований information-architecture exception.

ДжерелоGoogle Search Central — SEO link best practices for Google · Screaming Frog — Internal Linking Audit With the SEO Spider

ІнструментScreaming Frog SEO Spider

Точний шляхBulk Export → Response Codes → Client Error (4xx) Inlinks

Кроки

Експортуйте кожен 4xx destination разом із source inlinks.
Спочатку виправте source href; redirect додавайте лише за наявності реальної replacement page і legacy traffic.
Для typo URL виправляйте href, не покладайтеся на нескінченний redirect.
Після deploy re-crawl source templates.

Перевірку пройдено, якщо

У final verification crawl: 0 unintended internal links на 4xx.

Експортувати / зберегти: Source page, Anchor, Broken target, Correct target.

ДжерелоGoogle Search Central — Troubleshoot crawling errors and soft 404s · Google Search Central — SEO link best practices for Google

ІнструментScreaming Frog + manual review

Точний шляхInlinks/All Inlinks export; inspect image links

Кроки

Для priority pages експортуйте inlinks і перегляньте anchor distribution.
Замініть ambiguous “click here/докладніше”, де природно можна назвати destination.
Для linked images перевірте корисний alt, якщо image несе navigation meaning.
Не форсуйте exact-match keyword в кожний internal anchor.

Перевірку пройдено, якщо

Priority pages отримують зрозумілі contextual anchors із релевантних сторінок.
Meaningful image links мають корисний alt.

ДжерелоGoogle Search Central — SEO link best practices for Google

ІнструментScreaming Frog + View Source + DevTools

Точний шляхRaw crawl vs JS crawl; Original HTML / Rendered HTML

Кроки

Візьміть homepage, одну category/service page і щонайменше 3 representative content/detail templates.
Порівняйте H1, primary body, crawlable links, title, meta description і canonical в original response та rendered output.
Зафіксуйте поля, які JavaScript додає, видаляє або змінює, і component/template, що за це відповідає.
Залишайте normal HTML основною crawlable version. Не створюйте окрему Markdown- або llms.txt-копію контенту замість доступного HTML.

Перевірку пройдено, якщо

Essential content/links є в rendered HTML і не зникають після hydration.
Critical metadata стабільні між raw/rendered, якщо зміна не intentional.

Експортувати / зберегти: JavaScript filters + Original/Rendered HTML exports для повторюваних дефектів.

ДжерелоGoogle Search Central — Understand JavaScript SEO basics · Screaming Frog — SEO Spider configuration · Google Search Off the Record — Should I use markdown for my site?

ІнструментView Source + crawler

Точний шляхView page source; SEO Spider → JavaScript filters

Кроки

Перевірте title, meta robots і rel=canonical у initial response.
Порівняйте з rendered DOM.
Flag canonical-only-in-rendered-HTML і metadata updated by JavaScript.
Змініть framework template, щоб server/prerendered HTML віддавав final values.

Перевірку пройдено, якщо

Canonical/indexing directives не залежать від late client-side mutation на priority pages.

ДжерелоGoogle Search Central — Understand JavaScript SEO basics · Google Search Central — How to specify a canonical URL · Screaming Frog — SEO Spider configuration

ІнструментURL Inspection + Chrome DevTools

Точний шляхURL Inspection → View tested/crawled page → More info; DevTools → Network

Кроки

Live-test priority page у URL Inspection і перевірте rendered HTML/resources.
У DevTools Network увімкніть Disable cache, reload і filter failed requests.
Перевірте robots rules для JS/CSS/API paths, потрібних для main content.
Authentication/CORS/5xx для public rendering resources = engineering defect.

Перевірку пройдено, якщо

Немає unintentionally blocked або failed essential rendering resources.

ДжерелоGoogle Search Central — Fix Search-related JavaScript problems · Chrome for Developers — Network features reference

ІнструментScreaming Frog + DevTools

Точний шляхRaw vs JS crawl; Elements

Кроки

Порівняйте Unique Inlinks і discovered URL counts між raw та JS crawls.
Pagination/filter/load-more destinations, які мають crawl-итися, повинні мати реальні href URLs.
Не покладайтеся на onclick-only або fragment-only navigation для indexable pages.
Для infinite scroll забезпечте crawlable paginated URLs або інший supported path.

Перевірку пройдено, якщо

SEO-critical destinations discoverable без user-only interaction sequence.

ДжерелоGoogle Search Central — SEO link best practices for Google · Google Search Central — Understand JavaScript SEO basics

ІнструментChrome DevTools + curl

Точний шляхDevTools → Network → Size; або curl

Кроки

Виміряйте response size великих HTML documents і критичних fetched resources, а не оцінюйте розмір за кількістю рядків source.
Для HTML, що наближається до 2 MB, перевірте, чи title, canonical, robots directives, primary content та important links розташовані до cutoff.
Кожен subresource URL має власний fetch limit. 2 MB — не загальний page-weight budget.
Скоротіть server-generated payload або винесіть неessential data, якщо важливий crawlable content ризикує опинитися за fetched bytes.

Перевірку пройдено, якщо

HTML, потрібний для indexing, менший за 2 MB fetch limit, і жоден essential content/directive не розташований за цією межею.

Доказ: Запишіть HTML transfer/body size для найбільших templates і перевірте, що critical content з’являється до 2 MB boundary.

ДжерелоGoogle Search Central Blog — Inside Googlebot: crawling, fetching, and bytes processed · Chrome for Developers — Network features reference

ІнструментPageSpeed Insights

Точний шляхhttps://pagespeed.web.dev/ → URL → Mobile / Desktop

Кроки

Перевірте homepage і representative URL кожного high-traffic template.
Спочатку читайте Discover what your real users are experiencing, потім lab diagnostics.
Запишіть, чи data URL-level або origin-level; не приписуйте origin data конкретній сторінці.
Збережіть LCP, INP, CLS на 75th percentile окремо для mobile/desktop.

Перевірку пройдено, якщо

Зафіксовано scope field data: URL або origin.
Mobile і desktop значення збережено окремо.

Експортувати / зберегти: cwv-baseline.csv: URL, Scope, Device, LCP, INP, CLS, Date.

Джерелоweb.dev — Web Vitals: Core Web Vitals thresholds

ІнструментPageSpeed Insights + Chrome DevTools

Точний шляхPSI field data; DevTools Performance

Кроки

Запишіть польове значення LCP і статус перевірки.
У slow trace визначте LCP element і розділіть TTFB/server delay, resource-load delay, resource duration та render delay.
Якщо LCP — image, переконайтеся, що вона discoverable early, не lazy-loaded above the fold, має правильні dimensions/compression.
Після виправлення тестуйте той самий шаблон і той самий набір URL.

Перевірку пройдено, якщо

Good: LCP ≤2.5 s at p75.
Poor: >4.0 s; 2.5–4.0 s = needs improvement.

Джерелоweb.dev — Web Vitals: Core Web Vitals thresholds

ІнструментPageSpeed Insights + DevTools Performance

Точний шляхPSI field data; DevTools → Performance

Кроки

Запишіть field INP at p75.
Відтворіть slow interactions: menu, filter, accordion, cart, form typing.
Шукайте long main-thread tasks, heavy handlers і rendering після input.
Зменшуйте JS work/split tasks, а не оптимізуйте лише initial load.

Перевірку пройдено, якщо

Good: INP ≤200 ms at p75.
Poor: >500 ms.

Джерелоweb.dev — Web Vitals: Core Web Vitals thresholds

ІнструментPageSpeed Insights + Chrome DevTools

Точний шляхPSI field data; DevTools Performance/Layout Shift diagnostics

Кроки

Запишіть field CLS at p75.
Взаємодійте зі сторінкою достатньо довго, щоб спрацювали banners, fonts, lazy content, consent UI.
Reserve width/height або aspect-ratio для images, video, iframes, dynamic slots.
Не вставляйте content above existing content без user action.

Перевірку пройдено, якщо

Good: CLS ≤0.1 at p75.
Poor: >0.25.

Джерелоweb.dev — Web Vitals: Core Web Vitals thresholds

ІнструментChrome DevTools

Точний шляхDevTools → Network → Disable cache + Preserve log → reload

Кроки

Увімкніть Disable cache для наближення до first visit і Preserve log, якщо тест включає redirects/navigation.
Сортуйте за Size і Time; окремо перегляньте JS, CSS, Img та Fetch/XHR.
Зафіксуйте 10 найбільших first-load requests: URL, resource type, transferred size, initiator, blocking/priority behavior та owner.
Внутрішні byte budgets використовуйте лише для triage. Це не ranking thresholds Google; адаптуйте їх під продукт і connection profile.
Коли engineering потрібні timing/headers, експортуйте sanitized HAR і видаліть cookies, authorization headers та інші secrets.

Перевірку пройдено, якщо

10 найбільших first-load requests мають owner/justification; будь-який internal budget у backlog позначений як team target, а не вимога Google.

Експортувати / зберегти: Network → Export HAR (sanitized) + top-10 resource table.

ДжерелоChrome for Developers — Network features reference

ІнструментGoogle Rich Results Test

Точний шляхhttps://search.google.com/test/rich-results → URL

Кроки

Тестуйте representative URL кожного template зі structured data.
Спочатку виправляйте critical errors, потім warnings/recommended properties.
Markup має описувати visible content і використовувати найбільш specific relevant type, який підтримує Google.
Після deploy зробіть live URL Inspection, щоб перевірити, що Google бачить deployed markup.

Перевірку пройдено, якщо

0 critical structured-data errors на templates, які претендують на rich results.
Markup відповідає visible content і сторінка crawlable/indexable.

Доказ: Збережіть список результатів і помилок Rich Results Test для кожного шаблону.

ДжерелоGoogle Search Central — General structured data guidelines · Google Search Console — Rich Results Test · Google Search Console Help — URL Inspection tool

ІнструментCrawler + page source + sitemap

Точний шлях<link rel="alternate" hreflang>; EN/UA URL pairs

Кроки

На кожній localized canonical page перевірте hreflang=en та hreflang=uk на правильні canonical URLs.
Alternate page має посилатися назад на original page.
Використовуйте absolute URLs і лише live canonical 200 pages у hreflang set.
Якщо є x-default, він має вести на intentional default/fallback page.

Перевірку пройдено, якщо

Кожна EN/UA пара reciprocal, self-listed у set і веде на canonical 200 URLs.

Експортувати / зберегти: hreflang-pairs.csv: EN URL, UK URL, Reciprocal?, Status, Canonical.

ДжерелоGoogle Search Central — Tell Google about localized versions of your page

ІнструментCrawler + source

Точний шляхCanonicals + hreflang export

Кроки

English page canonical → English URL.
Ukrainian page canonical → Ukrainian URL.
Versions пов’язані через hreflang.
Переконайтеся, що перекладено і main body, і header/footer/navigation.

Перевірку пройдено, якщо

Кожна language page self-canonical і пов’язана hreflang.
Primary content реально localized.

ДжерелоGoogle Search Central — Tell Google about localized versions of your page · Google Search Central — How to specify a canonical URL

ІнструментТі самі tools, що в baseline

Точний шляхПовторіть raw crawl + JS crawl + URL Inspection samples + sitemap/robots checks

Кроки

Повторіть raw і JavaScript crawls з тим самим start URL, scope і configuration, що у baseline.
Порівняйте before/after URL sets для 4xx, 5xx, redirects, noindex, canonical conflicts, orphans і raw/rendered differences; headline counts можуть приховувати regression.
Для P1/P2 fixes повторіть original diagnostic path на representative affected URLs і live URL Inspection там, де це доречно.
Request indexing робіть лише після correct live state; повторні requests для незміненого URL не замінюють виправлення discovery або quality.
Закривайте item, коли в backlog є affected scope, expected result і before/after evidence, що проходить acceptance test.

Перевірку пройдено, якщо

Кожен critical fix має repeatable before/after evidence для початкового failure mode.
Verification crawl не показав нової regression у виправленому template або URL set.

Експортувати / зберегти: Збережіть фінальний crawl-проєкт, CSV повторної перевірки та докази для кожної задачі.

ДжерелоGoogle Search Console Help — URL Inspection tool · Google Search Console Help — Page indexing report · Google Search Central — How to perform a technical SEO audit

База джерел

Першоджерела, використані в чеклісті

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

Google Search CentralIn-depth guide to how Google Search works ↗
Google Search Console HelpPage indexing report ↗
Google Search Console HelpURL Inspection tool ↗
Google Search CentralBlock Search indexing with noindex ↗
Google Search CentralIntroduction to robots.txt ↗
Google Crawling InfrastructureUpdate your robots.txt file ↗
Google Search CentralBuild and submit a sitemap ↗
Google Search Console HelpCrawl Stats report ↗
Google Search CentralRedirects and Google Search ↗
Google Search CentralHow to specify a canonical URL ↗
Google Search CentralTroubleshoot crawling errors and soft 404s ↗
Google Search CentralSEO link best practices for Google ↗
Google Search CentralUnderstand JavaScript SEO basics ↗
Google Search CentralFix Search-related JavaScript problems ↗
Google Search Central BlogInside Googlebot: crawling, fetching, and bytes processed ↗
web.devWeb Vitals: Core Web Vitals thresholds ↗
Google Search CentralTell Google about localized versions of your page ↗
Google Search CentralGeneral structured data guidelines ↗
Google Search ConsoleRich Results Test ↗
Chrome for DevelopersNetwork features reference ↗
Screaming FrogSEO Spider configuration ↗
Screaming FrogHow to crawl JavaScript websites ↗
Google Search Off the RecordHow to read the Indexing Report ↗
Google Search CentralHow to perform a technical SEO audit ↗
Google Search Off the RecordShould I use markdown for my site? ↗
Screaming FrogInternal Linking Audit With the SEO Spider ↗

Потрібна допомога з упровадженням?

Потрібно перетворити аудит на implementation backlog?

Metricum Lab може перетворити дані crawl, Search Console і браузерної діагностики на пріоритезований технічний backlog із відповідальними командами, критеріями приймання та повторною перевіркою.

Переглянути послуги Technical SEO