Мінімум discoverability
Google рекомендує, щоб кожна важлива сторінка мала link хоча б з однієї іншої сторінки сайту.
Технічне SEO · Внутрішня перелінковка · Data-driven architecture
Внутрішня перелінковка для SEO: як побудувати масштабовану структуру посилань
Внутрішня перелінковка краще працює як система архітектури, а не quota. Поєднайте crawl data, Search Console, GA4 та page roles, щоб знайти сильні donors і цінні under-supported targets; створюйте зв’язки лише за тематичної та контекстної релевантності, а потім масштабуйте й валідуйте процес.
Коротка відповідь
Будуйте internal linking із page roles + evidence + relevance. Crawl data показує структуру, Search Console — search opportunity, GA4 — onsite/business context; donor→target pair має сенс лише тоді, коли source справді сильний, target заслуговує підтримки, а relationship тематично й контекстно природний. AI може прискорити пошук candidates, але не замінює evidence та human validation.
Links на сторінці
Google не задає універсальної ідеальної кількості посилань для сторінки.
Core Search Analytics metrics
API повертає clicks, impressions, CTR та average position разом із запитаними dimensions.
Search + onsite evidence
Search Console описує до-переходу поведінку; Analytics — взаємодію після візиту.
01 · Архітектура
Сприймайте внутрішню перелінковку як граф, а не як задачу “додати N посилань”
Корисне питання звучить не “де вставити ще один лінк?”, а “які зв’язки між сторінками повинна явно відображати архітектура сайту?”.
Google описує links одночасно як спосіб знаходити нові сторінки для crawl і як сигнал, що допомагає визначати релевантність сторінок. Тому одиниця роботи у внутрішній перелінковці — це зв’язок між двома сторінками, а не quota для окремої URL.
На сайті можуть бути тисячі internal links і водночас слабка архітектура. Важлива сторінка може залишатися глибоко в структурі, template modules можуть генерувати багато низькоконтекстних links, а нова URL — бути в sitemap, але майже не брати участі у внутрішньому графі.
Кастомна схема
У внутрішнього link graph є ролі, а не лише URL
Hub, сильні donor pages і under-supported targets утворюють мережу. Однакова кількість links може створити зовсім різну архітектуру залежно від того, що саме вони з’єднують і наскільки природний контекст.
Спочатку визначте роль сторінки
- Hub / category: організовує тему або набір продуктів і веде до важливих дочірніх сторінок.
- Donor candidate: технічно надійна та discoverable сторінка з достатньою видимістю/силою графа, яка може підтримати релевантний target.
- Target candidate: цінна сторінка, внутрішня підтримка якої слабша, ніж її роль або потенціал.
- Bridge: сторінка, що природно з’єднує суміжні кластери чи етапи user journey.
- Utility / non-search page: може бути потрібною користувачам, але не повинна автоматично потрапляти в SEO-prioritization.
Google також рекомендує, щоб кожна важлива для вас сторінка мала хоча б одне внутрішнє посилання з іншої сторінки сайту. Це варто трактувати як мінімальну умову discoverability, а не як завершену стратегію: одна URL може бути reachable і все одно залишатися глибокою, ізольованою від topic cluster або погано поясненою контекстом.
02 · Дані
Перед вибором donors і targets зберіть page-level dataset
Практична рекомендація для перелінковки починається з нормалізованого списку URL, де технічний стан поєднаний із search demand, onsite value та роллю сторінки.
Базова модель — один рядок на одну intended canonical page. Crawler дає структурний шар; Search Console — performance у Google Search; Analytics — поведінку після переходу та бізнес-результати. Backlink і log data можна додати для великих або складних сайтів. Мета — не “найбільша таблиця”, а можливість пояснити кожну рекомендацію даними.
| Шар | Що збираємо | Яке питання це закриває | Обмеження |
|---|---|---|---|
| Crawl / architecture | status, canonical, indexability, depth, inlinks, outlinks, template, page role | Чи може URL безпечно брати участь у графі? Чи вона ізольована/перелінкована надмірно? | Crawler бачить ваш crawl path, а не всю історію crawl Google. |
| Search Console | clicks, impressions, CTR, average position, query ↔ page relationships | Де вже є visibility, прихований search demand або сторінка близька до сильнішої позиції? | Position і CTR — контекст, а не самостійний “quality score”. |
| GA4 | sessions, engaged sessions, engagement rate, bounce rate, average session duration, key events, revenue за потреби | Чи сторінка підтримує корисний user journey і бізнес-результат після переходу? | Behavior metrics залежать від implementation і purpose сторінки; не перетворюйте їх на ranking proxy. |
| External / business | referring domains/authority estimate, priority, margin, freshness, owner | Які сторінки важливі стратегічно та які donors мають додаткову зовнішню підтримку? | Third-party authority metrics — оцінки, а не метрики Google. |
| Logs / crawl observations | bot requests, frequency, response patterns | Як bots реально звертаються до важливих templates та URL classes? | Logs показують requests, але не ranking value або intent. |
Зберіть baseline у відтворюваному порядку
- 1
Нормалізуйте URL inventory
Розгорніть redirects, зведіть відомі duplicates до canonical URL, яку аналізуєте, і додайте template/page-role labels. Excluded URLs збережіть окремим diagnostic set, а не видаляйте без сліду.
КритерійОдин аналітичний рядок відповідає одній intended canonical page; excluded/duplicate states збережені як evidence.
- 2
Приєднайте Search Console до canonical analysis URL
Вивантажте page-level Search Analytics, а де потрібно — page × query rows. Збережіть clicks, impressions, CTR та average position за чітко визначений період.
Шлях
Search Console API → Search Analytics: queryКритерійЗафіксовано date range, search type і dimensions; кожну метрику можна простежити до API/export.
- 3
Додайте GA4 як onsite context
Додайте organic sessions і ті engagement/conversion metrics, які відповідають задачі сайту. Зафіксуйте acquisition filter, яким визначали Google organic traffic.
Шлях
GA4 → Reports або Data APIКритерійAnalytics metrics явно позначені як onsite/user evidence і не використовуються як “link equity” чи прямий ranking score.
- 4
Зафіксуйте baseline snapshot
Збережіть dataset, час crawl та measurement window до зміни links. Саме цей snapshot використовуйте для re-crawl і post-release comparison.
КритерійCandidate list можна відтворити зі збереженого baseline, а не лише з dashboard, який постійно змінюється.
Для дуже великих properties Bulk data export Search Console у BigQuery спрощує page/query joins і регулярний scoring. Для меншого сайту достатньо API/export + crawler: складність pipeline має відповідати масштабу задачі.
03 · Пріоритизація
Знайдіть “вершини” й “низини”, але оцінюйте зв’язок, а не сторінки окремо
“Вершини й низини” — це модель пріоритизації: сильні релевантні donors підтримують цінні under-supported targets. Сильна сторінка не стає donor для будь-якої слабкої URL.
Вершина — потенційний donor: технічно стабільна, discoverable, добре вбудована у структуру сторінка, яка має сенс у темі конкретного target. Низина — потенційний target: сторінка з цінністю або потенціалом, але з недостатньою підтримкою графа. Високий/низький traffic сам по собі не визначає ці ролі.
Для кожної donor→target пари я б ставив чотири окремі питання: наскільки сильний donor? наскільки цінна opportunity у target? наскільки сторінки тематично споріднені? і чи є на source page природний контекст, де link реально допомагає читачеві?
Кастомна схема
Вершини й низини: donor strength проходить через relevance
Performance і graph signals допомагають знайти peaks/valleys, але topical relevance та реальний context source page вирішують, чи вартий зв’язок посилання.
| Компонент | Можливі evidence | Що підсилює score | Що має його знижувати |
|---|---|---|---|
| Donor strength | visibility, internal inlinks, crawl depth, external support, page role | стабільна canonical page з meaningful visibility та graph connectivity | redirect/noindex, застарілий контент, слабка роль, нерелевантний template |
| Target opportunity | impressions, position band, business priority, under-linking, depth, query coverage | цінна сторінка з demand/strategic role та слабкою підтримкою | неясний purpose, duplication, unresolved indexability, intentionally excluded URL |
| Topical relevance | query overlap, entities, taxonomy, page-role relationship, semantic similarity | спільний task/topic/entity set і логічний user journey | лише lexical similarity без змістовного зв’язку |
| Context fit | реальний paragraph, section, component/navigation state | читачеві корисно перейти на target саме тут | link потрібен лише для score або exact-match keyword |
04 · Індексація
“Not indexed” — це diagnostic state, а не автоматично найглибша “низина”
Неіндексована URL стає пріоритетним target лише після того, як ви довели, що вона взагалі повинна бути в індексі та що internal support пов’язана з проблемою.
Інтуїтивне правило звучить так: “не індексується = найбільша низина”. Я б змінив його на “не індексується = найвищий diagnostic priority”. Search Console прямо зазначає, що статус not indexed не завжди є проблемою: частина URL навмисно excluded, duplicate, alternate canonical або просто не має бути search landing page.
Проведіть діагностику до додавання links
- 1
Вирішіть, чи URL повинна індексуватися
Почніть із purpose. Якщо це duplicate, parameter state, utility/private page або інша URL не для Search — приберіть її з target pool замість спроб “підсилити”.
КритерійДля кожного non-indexed candidate є явне рішення “should index: yes/no” з причиною.
- 2
Перевірте indexing reason і поточний стан сторінки
Використайте Page Indexing та URL Inspection. Перевірте status, crawl allowance, noindex, canonical selection і live availability.
Шлях
Search Console → URL InspectionКритерійВідомі indexability/canonical state; відсутність в індексі не трактується як generic internal-link issue.
- 3
Виправте найраніший blocking cause
Якщо URL noindex, canonicalized на іншу сторінку, broken, duplicate або технічно ненадійна — спочатку виправте або свідомо залиште цей стан. Internal links не повинні суперечити intentional exclusion strategy.
КритерійСторінка повертає потрібний status, directives і canonical relationship до пріоритетної роботи з links.
- 4
Додавайте internal support, коли discovery/graph isolation усе ще правдоподібна причина
Коли URL корисна, indexable і canonical, під’єднайте її з релевантних crawlable pages і повторіть inspection/re-crawl. Перелінковка тут — один remediation step, а не універсальний fix індексації.
КритерійTarget reachable через crawlable HTML links із релевантних сторінок, а новий шлях присутній у rendered output.
05 · Релевантність
Зіставляйте donors і targets за темою та наступним корисним кроком користувача
Semantic similarity — хороший фільтр, але фінальне рішення має проходити перевірку в реальному контексті source page.
У guidance Google є дуже практичний критерій: anchor text має бути descriptive, reasonably concise і relevant як до source, так і до destination; слова навколо link також створюють context. Тому оцінювати треба не лише embeddings двох сторінок, а й конкретний source passage.
Поєднуйте кілька relevance signals
- Query relationship: чи сторінки закривають суміжні або послідовні search tasks?
- Shared entities/concepts: чи це одна product family, technology, location, problem або workflow?
- Taxonomy: чи category/subcategory або hub/spoke вже описує relation?
- User journey: чи target природно потрібен читачеві наступним?
- Page role: чи краще показати зв’язок contextual link, breadcrumbs, hub, navigation або template rule?
- Passage fit: чи є речення/компонент, де link уточнює наступний крок без переписування тексту під keyword?
Механізм обирайте після того, як relation зрозумілий. Contextual editorial link добрий, коли source text уже вводить target concept. Breadcrumbs описують ієрархію. Hub/category modules — membership. Navigation — persistent importance. Related-content modules допомагають exploration, але не повинні перетворюватися на випадковий блок “SEO links”.
06 · Кількість links
Універсальної відповіді “скільки внутрішніх посилань має бути на сторінці” немає
Кількість links є наслідком функції сторінки та information architecture, а не site-wide quota.
Google прямо пише, що магічної ідеальної кількості links для сторінки немає. Тому правила “30 links per page” або “додати п’ять contextual links у кожну статтю” — слабкі defaults. Product category, довгий research guide і login screen мають різні navigation needs.
Замість quota використовуйте обмеження, які захищають usefulness
- Кожна важлива сторінка має бути reachable хоча б через один crawlable internal link і бажано через шлях, що відповідає її ролі.
- Кожен link має додавати navigation, context або architecture value; відкидайте candidates, що існують лише через “вільне місце” у score.
- Template-generated links потребують жорсткішого governance, бо одна помилка масштабується на тисячі URL.
- Dense navigation може бути нормальною для inventory/directory; надмірна кількість contextual links може погіршувати читання.
- Якщо одна сторінка генерує сотні candidates, перевірте, чи вам не потрібні hub, filter, category або template component замість нових inline anchors.
Для automation все одно можна задати operational cap, наприклад “повертати не більше N candidates на source для human review”. Це workflow constraint для контролю noise/QA, а не SEO threshold і не твердження про те, скільки links “хоче Google”.
07 · Масштабування
Перед автоматизацією перетворіть повторювані рекомендації на правила архітектури
На великому сайті правильним fix часто є один template rule, а не сотні ручних вставок.
Manual linking перестає масштабуватися, коли однаковий relationship повторюється на product pages, documentation, location pages, programmatic landing pages або multilingual inventory. Перед automation individual insertions згрупуйте candidate pairs за relationship type. Якщо 750 product pages потребують link на відповідний category hub, справжнім artifact може бути одне протестоване template rule.
| Поле правила | Приклад питання | Навіщо це потрібно |
|---|---|---|
| Eligible source roles | Які templates можуть створювати relationship? | Не дає global rule потрапити в нерелевантні page types. |
| Eligible target roles | Які canonical/indexable targets можуть його отримувати? | Не допускає redirects, noindex та duplicate variants у production links. |
| Relevance gate | Який taxonomy/entity/query relationship має бути true? | Робить relevance перевірюваною до deployment. |
| Placement mechanism | Contextual passage, breadcrumb, hub, related module чи navigation? | Кодує architecture intent, а не просто генерує href. |
| Operational cap | Скільки candidates система повертає на review? | Контролює review noise; це не Google link-count rule. |
| Validation | Що re-crawl повинен довести після release? | Робить automation reversible і testable. |
08 · AI-assisted workflow
Використовуйте AI-агентів, щоб скоротити пошук candidates, а не вигадувати evidence
AI корисний для classification, semantic matching і context inspection, якщо evidence contract чіткий, а production changes залишаються контрольованими.
На сайті з десятками тисяч URL donor-target matrix занадто велика для ручного порівняння. AI може класифікувати page roles/topics, cluster entities, ранжувати semantically plausible pairs, перевіряти реальний donor passage і формувати review queue. Але evidence для рекомендації все одно має походити з crawl, Search Console, Analytics, URL state та source content.
Кастомна схема
Evidence-led AI loop для internal linking
Agent отримує нормалізовані site data і constraints, ранжує candidates, повертає explainable suggestions та передає implementation людині або контрольованому rule. Re-crawl і measurement закривають цикл.
Дайте агенту evidence contract
- Goal: знайти internal-link candidates для чітко визначеного target cohort, а не “оптимізувати весь сайт”.
- Allowed inputs: normalized crawl, GSC/GA fields, approved page-role taxonomy та page content.
- Eligibility: source/target мають бути canonical indexable 200 pages, якщо task явно не діагностує exclusions.
- Relevance rule: потрібні topical match і природний passage/context.
- Forbidden actions: без autonomous production edits, без видалення existing links, без invented metrics або ranking claims.
- Output: source URL, target URL, suggested placement/anchor, component scores, evidence та uncertainty.
- Stop condition: low relevance, missing content, conflicting canonical/index state або insufficient evidence → manual review.
Ілюстративний review object від internal-linking agent
{
"sourceUrl": "https://example.com/guides/technical-seo/",
"targetUrl": "https://example.com/guides/internal-linking/",
"relationship": "technical-seo -> internal-linking methodology",
"scores": {
"donorStrength": 0.82,
"targetOpportunity": 0.76,
"topicalRelevance": 0.91,
"contextFit": 0.85
},
"evidence": {
"sourceStatus": 200,
"targetIndexable": true,
"targetImpressionsWindow": "defined in baseline dataset",
"matchingSection": "Site architecture and crawl paths"
},
"suggestedAnchor": "internal linking architecture",
"action": "human-review",
"confidence": "medium"
}Це лише illustrative schema. Числові значення — внутрішні normalized scores, а не Google metrics; агент має повернути underlying evidence, щоб reviewer міг відхилити рекомендацію.
09 · Валідація
Спочатку перевірте новий graph, потім вимірюйте target cohorts у часі
Implementation завершена лише тоді, коли новий relationship є у rendered output, target лишається валідним, а baseline можна порівняти з post-release data.
Закрийте цикл після release
- 1
Повторно crawl source і target cohorts
Переконайтеся, що source повертає 200, містить crawlable <a href> на intended canonical target і не створює redirect/noindex hops.
КритерійSource→target edge є у crawlable HTML/rendered output; URL states відповідають rule.
- 2
Перерахуйте graph diagnostics
Порівняйте depth, inlink counts, orphan/near-orphan state та rule coverage з baseline. Перевірте, що automation не створила unrelated link explosion.
КритерійTarget cohort отримав потрібну структурну підтримку без неочікуваних cross-cluster edges.
- 3
Моніторте Search Console за target cohort
Порівнюйте clicks, impressions, CTR, position і page/query relationships за однаковим post-release window. Не робіть causal claims за однією URL або кількома днями volatility.
Шлях
Search Console → Performance або Search Analytics APIКритерійДо/після використовують однакові metric definitions і filters, target cohort збережений.
- 4
GA4 — для onsite outcomes, не як заміна Search data
Перевірте, чи linked journey дає корисні sessions, engagement або business events. Очікуйте, що clicks і sessions відрізнятимуться, бо Search Console та Analytics мають різні системи й визначення.
КритерійSearch і onsite metrics показані поруч із джерелом, а не злиті в один undocumented success score.
| Рівень | Pass evidence | Що вимірювати | Обмеження |
|---|---|---|---|
| Technical | crawlable source href; intended target status/canonical; no broken hops | edge exists, target state, depth, inlinks | доводить implementation, а не ranking impact |
| Search | consistent target cohort before/after | impressions, clicks, CTR, position, query coverage | на Search performance одночасно впливає багато факторів |
| User / business | linked journeys залишаються корисними | sessions, engaged sessions, key events, revenue за потреби | metrics залежать від instrumentation і page purpose |
| System quality | rule генерує релевантні candidates з низьким rejection/error rate | coverage, reviewer rejection, duplicate/invalid candidate rate | внутрішній QA metric, не search-engine metric |
Для більшої causal confidence використовуйте controlled rollout, якщо architecture дозволяє: змінюйте один relationship class, фіксуйте source/target cohorts, не поєднуйте реліз із великими template/content changes і запишіть release date. Навіть тоді organic movement краще називати evidence consistent with intervention, а не доказом, що один link спричинив конкретну ranking change.
10 · Operating model
Використовуйте один повторюваний decision chain для кожної зміни перелінковки
Масштабована система явно пояснює, чому link додається, чому інший candidate відхиляється і як результат буде перевірений.
Рекомендований порядок роботи
- 1. Inventory: визначте intended canonical pages і excluded states.
- 2. Roles: позначте hubs, donors, targets, bridges і utility pages.
- 3. Evidence: поєднайте crawl, Search Console, GA4 та business signals за визначений період.
- 4. Prioritize: знайдіть peaks/valleys без трактування traffic як authority.
- 5. Match: вимагайте topical relevance і real context fit.
- 6. Mechanism: оберіть contextual link, breadcrumb, hub, navigation, related module або template rule.
- 7. Review/implement: AI suggestions мають бути explainable, production changes — контрольованими.
- 8. Re-crawl: доведіть існування edge і правильний target state.
- 9. Measure: порівняйте target cohorts у Search Console та onsite outcomes у GA4.
- 10. Iterate: повторювані корисні patterns перетворюйте на maintainable architecture rules.
Практичний принцип: не переносіть “link equity” сліпо зі сторінок із великими числами на сторінки з малими числами. Спочатку вирішіть, чого заслуговує target; потім знайдіть релевантний donor і правильний mechanism; після цього перевірте, що relationship існує й залишається корисним.
Головне обмеження — attribution. Internal linking змінює architecture, discovery paths і context, але Search performance залежить від багатьох систем одночасно. Метод найсильніший тоді, коли спочатку створює кращу, explainable site structure — навіть до того, як ви побачите ranking change.
Першоджерела та документація
Джерела
Кожне змінне твердження про пошукову систему, браузер, інтерфейс або технічну поведінку в матеріалі прив’язане до актуального першоджерела.
- Google Search Central Link best practices for Google (відкриється в новій вкладці)Першоджерело про crawlable links, контекст внутрішніх посилань, anchor text і відсутність універсальної «правильної» кількості посилань.
- Google Search Console API Search Analytics: query (відкриється в новій вкладці)Офіційні поля Search Analytics API: clicks, impressions, CTR, average position та dimensions.
- Google Search Central Using Search Console and Google Analytics data for SEO (відкриється в новій вкладці)Пояснює різницю між даними до переходу з Google Search та поведінкою на сайті, а також чому GSC і GA4 не повинні збігатися один в один.
- Google Analytics API dimensions and metrics (відкриється в новій вкладці)Офіційні визначення sessions, engaged sessions, engagement rate, bounce rate, average session duration та revenue/key-event metrics.
- Google Search Console Help Has Google found all your pages? (відкриється в новій вкладці)Офіційна документація Page Indexing: not indexed не завжди є проблемою; важливо перевірити цінність URL та конкретну причину.
- Google Search Console Help Inspect and troubleshoot a single page (відкриється в новій вкладці)Офіційний workflow для перевірки indexed/live стану URL і можливих блокерів.
- Google Search Console API Method: index.inspect (відкриється в новій вкладці)Офіційний API для програмної перевірки index status; API повертає дані про indexed version і не виконує live test.
- Google Search Central Block Search indexing with noindex (відкриється в новій вкладці)Першоджерело про noindex і необхідність доступу crawler до сторінки, щоб побачити директиву.
- Google Search Central What is canonicalization (відкриється в новій вкладці)Першоджерело про duplicate URL clusters, canonical selection і сигнал канонікалізаціїs; документацію оновлено 2026-08-20 UTC.
- Google Search Central SEO Guide for Web Developers (відкриється в новій вкладці)Першоджерело про reachable pages, релевантні links та discoverable site structure.
- Google Search Central Blog Bulk data export: a new and powerful way to access your Search Console data (відкриється в новій вкладці)Офіційний спосіб вивантажувати великі масиви Search Console у BigQuery для масштабованого page/query analysis.
- Google Search Console Help About Search Console data (відкриється в новій вкладці)Пояснює обмеження coverage у Search Console reports і роль URL Inspection для конкретної URL.
Потрібна допомога з діагностикою та впровадженням?
Перетворіть модель на implementation-ready backlog внутрішньої перелінковки
Metricum Lab може поєднати crawl architecture, Search Console/analytics evidence та business priorities у donor-target map, template rules і validation plan, не змішуючи інформаційну методологію з комерційним audit workflow.
Переглянути аудит та оптимізацію internal linking