Analyze internal links in GSC

Use Google's sampled internal-link view without treating it as a substitute for a site crawl.

Directional evidence Additional data required Intermediate

Search Console's Links report offers a useful Google-observed sample of internal links. It can show which canonical pages receive many reported internal links and, for a listed target, examples of pages that link to it.

It cannot provide a complete link graph, prove that a page is orphaned, report internal anchor text, or replace a crawl. Use it as one evidence layer: compare Google's sample with your intended information architecture, then validate suspected gaps using a crawler and a complete URL inventory.

This guide reflects Google's documentation on July 18, 2026.

What the internal Links table shows

Open Search Console → Links → Internal links → Top linked pages → More.

The table ranks pages in the current property by reported incoming links from within that property. Select a target to see sampled source pages linking to it. Google says this view can help confirm that core pages are properly linked and that users can move between relevant pages efficiently.

The report applies the general Links-report processing rules:

data is sampled rather than comprehensive;
interface tables are limited to 1,000 rows;
targets are grouped by Google's canonical URL;
duplicate source-to-target links are combined after parameter removal and normalization;
links Google found in the past may remain after removal or source deletion;
attributes such as nofollow are not shown.

These rules mean the number is a report count, not a raw count of <a> elements in current HTML.

Property scope changes “internal”

Internal means inside the selected property, not necessarily inside the organization or root domain.

Suppose blog.example.com/article links to www.example.com/product:

in a Domain property for example.com, both URLs are in scope and the relationship can be internal;
in a URL-prefix property for https://www.example.com/, the blog source is outside scope and can be treated as external.

Record the property before comparing reports. If teams own separate subdomains or directories, analyze both the Domain property and relevant URL-prefix properties when available: the first gives a broad ecosystem view, while the narrower views can isolate a managed area.

Canonical grouping changes the target

The table groups a target under Google's canonical URL. Internal links may point to:

tracking or session parameters;
HTTP or alternate-host variants;
faceted or sorted variants;
old URLs that redirect;
duplicate pages whose canonical is elsewhere.

The visible row can therefore differ from the literal href. This is useful evidence of consolidation, but it can hide inconsistent internal linking.

When a target looks surprising:

Inspect the target's indexed result in URL Inspection.
Compare Google's canonical with the user-declared canonical.
Crawl the site to extract literal source href values.
Check redirects and final responses.
Update controlled internal links to the preferred canonical URL.

Google recommends linking internally to the canonical URL rather than a duplicate. Consistent links reduce unnecessary redirects and make the preferred version clearer.

Find pages receiving the most internal links

The top of the table often contains global navigation, footer, legal, account, category, and major hub pages. A high count is not automatically good or bad: a privacy page can appear sitewide because users need it, while a strategically important seasonal landing page may appropriately receive fewer contextual links.

Classify visible rows before interpreting them:

Page class	Typical expectation	Question to ask
Home and primary hubs	High	Does the hierarchy match how users browse?
Key categories or services	High to moderate	Are priority areas easy to reach?
Detail pages	Varies with inventory and value	Are links contextual and from relevant hubs?
Editorial resources	Varies with topic network	Do related guides connect naturally?
Utility, legal, login	Often high due to templates	Is the prominence functional rather than accidental?
Filters, parameters, pagination	Controlled	Are crawlable links creating unwanted URL expansion?
Redirects and errors	Ideally none from controlled templates	Which source templates need correction?

Avoid comparing unlike page types. A product, category, article, and legal page serve different roles and should not share one arbitrary link-count target.

Compare the sample with intended priorities

Build a list of URLs the organization considers important, with fields such as:

canonical URL;
page type and directory;
business or editorial priority;
intended parent hub;
indexability and response status;
Search clicks or conversions where appropriate.

Join that list to the internal Links export or manually check priority targets. Flag hypotheses rather than declaring defects:

Important and highly represented: validate link quality and hierarchy; no automatic action is needed.
Important and weakly represented: inspect the intended parent, contextual opportunities, crawlability, and canonical grouping.
Low priority and highly represented: determine whether a template, faceted navigation, or utility link explains the count.
Missing from the sample: investigate with a crawl; do not label it orphaned yet.

Counts can help prioritize inspection, but they do not measure relevance, placement, anchor clarity, click depth, traffic, or link equity directly.

Search Console does not report internal anchor text

The report's Top linking text card covers links from outside the property. There is no equivalent complete internal-anchor table.

To review internal anchor text, extract it with a crawler, rendered-DOM process, or CMS query. Evaluate whether the text is descriptive, reasonably concise, relevant to both pages, and natural in its surrounding sentence. Google explicitly advises against generic anchors and keyword stuffing.

For image links, useful alt text can provide link context. For links inserted with JavaScript, use URL Inspection's rendered output on representative pages to confirm the anchor exists in rendered HTML.

Why GSC cannot identify orphan pages reliably

An operational definition of an orphan is usually: a canonical, indexable URL in the known site inventory with zero incoming crawlable internal links.

Search Console does not supply either required complete set:

Its Links report is a sample, not every internal edge.
It is not a complete inventory of all URLs the site intends to maintain.

A URL absent from the table may be linked but omitted from the sample. Conversely, a URL shown in the table may only have historical links that no longer exist.

Use a crawler and reconcile at least these inventories:

crawl-discovered URLs;
XML sitemap URLs;
CMS or database URLs;
analytics landing pages;
server-log URLs;
Search Console indexed or inspected samples;
feeds or commerce-system exports when applicable.

Normalize redirects, parameters, fragments, protocol, host, trailing slashes, and canonicals before calculating inlinks. Then investigate canonical, indexable URLs with zero crawlable internal inlinks.

Crawlability matters more than visual clickability

Google generally relies on an <a> element with an href containing a resolvable URL. A control that looks and behaves like navigation for a browser may not be a reliably crawlable link if it uses only:

a <span> or other non-anchor element;
an anchor without href;
an onclick handler that contains the destination only in script;
a search form that Googlebot would need to submit;
state available only after user interaction.

Google can process dynamically inserted links when rendered as proper <a href> markup. Test representative templates in URL Inspection and crawl with JavaScript rendering when architecture depends on client-side code.

Mobile output also matters because Google indexes the mobile version. If desktop and mobile templates expose different internal links, validate the set available to Google on mobile.

Analyze click depth and architecture outside GSC

Search Console reports source examples and target counts, but it does not calculate shortest click depth from the homepage or expose the whole graph.

A crawler can calculate:

shortest click depth;
incoming unique source pages;
internal links by template and placement;
broken, redirected, canonicalized, or non-indexable targets;
pages with only one inlink;
links present only after rendering;
internal anchor text and surrounding context;
strongly and weakly connected sections.

Google says it can use both the number of links needed to reach a page and the number of links to a page to infer relative importance. For commerce navigation, its example path is menu → category → subcategory → product. Search boxes alone are insufficient because Googlebot generally does not submit searches to discover products.

Use this principle for any site type: important pages should be reachable through clear, crawlable, user-useful paths, not merely listed in a sitemap.

A practical investigation workflow

1. Capture the GSC evidence

Record property scope and date.
Export the internal top-linked-pages table.
Label canonical targets by page type and intended priority.
Drill into representative high, low, and surprising targets.

2. Crawl the site

Start from the canonical public entry points.
Enable rendering if the site relies on JavaScript navigation.
Include sitemaps and other known URL sources.
Extract status, indexability, canonical, depth, inlinks, and anchor text.

3. Reconcile rather than force equality

Expect differences caused by sampling, canonical grouping, normalization, historical discovery, and crawl configuration. Investigate patterns:

GSC sees sources that the crawler cannot fetch now;
the crawler sees links absent from the sample;
GSC groups variants under a canonical;
the crawler finds literal links through redirects;
rendered and raw-HTML crawls disagree.

4. Choose page-level actions

Possible actions include:

add a useful contextual link from a relevant hub or article;
expose detail pages through crawlable category or listing navigation;
link directly to final canonical destinations;
remove or constrain links generating unbounded faceted URLs;
repair links to 4xx and 5xx targets;
replace vague or misleading anchor text;
consolidate duplicate hubs only when their user purpose overlaps.

Do not add links merely to increase a count. Every new link should help a user discover or understand the destination.

5. Validate after release

Recrawl immediately to confirm the implementation. Use URL Inspection on a small representative sample to verify rendered links and canonical state. Search Console's Links sample may update later and is not a release-monitoring system, so do not wait for its counts as the only proof of success.

What can be automated

Search Console has no supported API for the Links report. Downloading its internal table requires the UI, and table export remains bounded by the documented table limit.

With external data, teams can automate:

complete internal-link extraction from scheduled crawls;
joins against sitemap, CMS, analytics, and conversion inventories;
orphan and low-inlink candidates after URL normalization;
click-depth and broken-link monitoring;
template and directory comparisons;
alerts for new links to redirects, errors, or non-canonical targets.

SearchConsole.ai can inspect supplied URLs for Google canonical, user canonical, robots, fetch, and index state. It cannot retrieve the Links report or discover the site's complete internal graph. Provide crawler output or a URL list when asking it to help triage internal-link candidates.

Ask SearchConsole.ai: Inspect these priority URLs from our internal-link crawl. Group them by indexed status, Google-selected canonical, user-declared canonical, robots.txt access, and fetch result. Keep link-count recommendations separate from indexing evidence.

Common mistakes

Treating absence from a sampled table as proof of an orphan.
Assuming the 1,000 visible rows cover the whole site.
Comparing URL-prefix and Domain properties without accounting for scope.
Reading canonical target counts as literal href counts.
Assuming every reported source link is still live.
Looking for internal anchors in the external link-text table.
Setting a universal “ideal” number of internal links.
Adding sitewide links solely to inflate counts.
Ignoring mobile and rendered navigation.
Using sitemap inclusion as a replacement for internal navigation.
Waiting for GSC to validate a release that a crawler can verify directly.