Internal Linking Audit for Small Sites

Direct answer: audit internal links by exporting the site's important pages and every crawlable link between them, assigning each page a job, and then reviewing reachability, crawl depth, link direction, anchor text, link position, and destination health. Prioritize important pages with no contextual inlinks, useful pages reached only through weak routes, dead ends, links to redirects or errors, and missing paths from information or proof to the right commercial next step. Re-crawl after the edits. Do not turn the total number of links into a universal score.

This guide owns the sitewide distribution problem across pages that already exist. The focused orphan-page workflow covers the narrower job of finding URLs with no useful path from the main graph and deciding whether they should be reconnected, merged, excluded, or removed.

What an internal linking audit measures

Signal	Useful question	Important limitation
Reachability	Can a crawler and reader reach the page through normal links?	A sitemap or known URL can expose a page without repairing the internal route.
Crawl depth	How many followed links separate the chosen start page from this URL?	The number depends on crawl start, scope, rendering, and how the tool counts redirects.
Unique inlinks	How many distinct pages link to the target?	Sitewide navigation can inflate counts without adding much contextual guidance.
Link direction	Does the route move a reader to the next useful task, proof item, or buying step?	More reciprocal links are not automatically better.
Anchor and context	Can someone understand the destination before following?	Exact-match repetition is not a substitute for clear language.
Destination health	Does the link resolve directly to the intended canonical page?	A redirect can work while still hiding stale URLs and distorting tool depth.

There is no single healthy number for every page. A privacy page can be useful with only sitewide footer access. A core service page may need several contextual routes from guides and proof. A deep specialist article may be appropriate when its parent hub and related tasks make the route clear.

1. Define the scope and page jobs

Start with one preferred URL inventory. Include canonical, indexable HTML pages that users can reach, plus any redirecting, error, non-indexable, or duplicate destinations currently receiving internal links. Exclude assets, tracking URLs, logout routes, staging hosts, and parameter combinations that are outside the public site job.

Assign each important page one primary role:

Hub or category: helps a reader choose a narrower task.
Guide or task page: answers a problem and points to the next relevant action.
Service or product: explains scope, fit, price boundaries, or a buying path.
Proof: supports a claim through a case, result, example, credential, or methodology.
Support or policy: answers operational, legal, account, or trust questions.

This role map prevents a common audit mistake: treating every low-link page as broken. Importance comes from the page's job and current business model, not from its URL type or publication date alone.

Run a control crawl from the homepage or the true root of the section. Do not seed the first crawl with the sitemap, Search Console, analytics, or a saved URL list. Imported URLs are useful later, but they can make a disconnected page look reachable.

Google says it can generally crawl an internal link when it is an <a> element with an href, and it recommends placing descriptive anchor text inside the link. If important routes rely on JavaScript, compare raw and rendered HTML and use URL Inspection for a representative page.

Export at least these fields:

source URL and target URL;
source and target page role;
HTTP status, indexability, and declared canonical;
crawl depth and unique inlink count;
anchor text and link position, such as content, navigation, sidebar, or footer;
whether the source and target are present on mobile and in rendered HTML.

Record the crawl configuration. Start URL, subdomain rules, rendering mode, robots handling, canonicals, and redirect counting can change the output. A number without that context is not a stable baseline.

3. Build a reviewable link worksheet

Keep one row per source-to-target relationship that needs review. The worksheet should preserve the observed route, the page roles, the issue, the decision, and the validation date. This makes a second review possible and stops a bulk link count from becoming the deliverable.

Audit date:
Start URL and crawl scope:
Rendering mode:
Included page roles:
Excluded URL classes:
Priority pages:

Source URL:
Target URL:
Source role:
Target role:
Link position:
Anchor text:
Target status / indexability / canonical:
Observed issue:
Decision: ADD / KEEP / REWRITE / MOVE / REMOVE / UPDATE TARGET / REVIEW PAGE
Owner:
Validation date:

4. Separate orphan, underlinked, deep, and dead-end pages

State	Operational test	Likely next decision
Orphan candidate	Found in an independent inventory but absent from the control crawl	Verify scope, then reconnect, merge, exclude, or remove
Underlinked	Reachable, but important to the business and supported only by weak or template routes	Add a small number of relevant contextual inlinks
Deep	Requires an unexpectedly long path from the chosen start page for its role	Shorten the route from a real hub or relevant source
Dead end	Answers the current question but offers no useful onward route beyond generic navigation	Add the next task, evidence, support, or commercial path
Overlinked	Receives many repetitive or irrelevant routes that do not match reader need	Remove noise and keep the most useful paths

Do not apply a universal “three clicks from the homepage” rule. Use depth as a review trigger. A critical service, category, or policy page should be easy to reach for its users. A narrow supporting article can sit deeper when its parent and sibling routes are clear.

If a candidate is missing from the crawl entirely, stop this broad audit and use the orphan-page comparison workflow. It brings in sitemap, Search Console, analytics, logs, and CMS inventories without confusing discovery with a healthy internal route.

5. Audit link direction by reader movement

Review whether each page sends a reader to the next reasonable decision. A small site usually needs several deliberate directions:

From	To	Reader reason
Hub or broad guide	Specific task page	Move from orientation into implementation
Task guide	Related task	Continue diagnosis, implementation, or validation
Informational guide	Service or product	Offer help when the reader is ready to act
Service or product	Proof or methodology	Support a buying claim with inspectable evidence
Proof page	Relevant service	Connect the demonstrated result to the available offer
Support or policy	Relevant action page	Resolve a trust question and return the user to the task

The topic-cluster planning guide defines page jobs before publication. This audit checks whether those intended routes exist on the live site. Do not force a service link into every article. Add it only where the next step is honest and useful.

6. Review anchor text and link context

Google recommends anchor text that is descriptive, reasonably concise, and relevant to both the source and destination. W3C guidance also requires that a link's purpose can be understood from the link text or its programmatically determined context.

Prefer anchors that name the destination's job, such as “orphan-page workflow” or “SEO audit scope”.
Use natural variation when the surrounding sentences discuss different aspects of the same page.
Replace vague repeated anchors such as “click here” or “learn more” when the surrounding context does not make the destination clear.
For linked images, provide useful alt text because Google can use it as anchor text.
Do not rewrite every anchor to the same keyword phrase. Clarity and reader expectation come first.

Inspect placement as well as wording. One contextual link inside a relevant explanation can serve a different reader need from the same target repeated across every navigation or footer template.

7. Fix broken, redirecting, and conflicting destinations

Filter the internal edge export for destinations that return 3xx, 4xx, or 5xx; canonicalize elsewhere; use an unintended hostname or protocol; or point to a fragment whose target element no longer exists. A fragment that jumps to a valid section is not a broken internal link. Treat fragments as a separate architecture problem when the site uses them to load a different primary content state; Google advises against using fragments to change page content. Also inspect links present on desktop but missing from the mobile version.

A redirecting internal link is not the same as a broken link, but it can preserve stale URLs, add latency, and change a crawler's reported depth. Update the source to the final canonical destination when that destination is known and appropriate. Do not bulk-replace a redirect until you confirm that path and query behavior remain correct.

If two live pages blur the same job, do not try to solve the conflict by adding more links to both. Use the Search Console cannibalization workflow to decide whether they should stay separate, merge, redirect, or be repositioned.

8. Prioritize a small repair batch

Rank fixes by page importance, route weakness, relevance of the proposed source, user benefit, and edit risk. A short reviewable batch is safer than adding links sitewide from a script.

Pattern	Decision	Reason
Important page has no relevant contextual inlink	Add one or two links from pages that naturally lead to it	Repairs both discovery and reader movement
Page has many template links but no useful context	Add a relevant body link, not another sitewide repetition	Clarifies why the destination matters here
Low-value page is a merge or removal candidate	Decide the page first	More links can preserve unnecessary content debt
Link points through a known redirect	Update to the final URL after validating behavior	Removes stale routing and an avoidable hop
Page links to every service regardless of topic	Remove irrelevant routes	Reduces choice noise and misleading next steps
Useful page ends without a next action	Add the next task, proof item, or support route	Repairs a real dead end

Do not describe this as PageRank sculpting. The practical objective is a logical, crawlable structure that lets people understand where they are, what the destination does, and what action makes sense next.

9. Validate the new routes

Re-run the crawl with the same start point, scope, and rendering settings.
Confirm the intended source-to-target edges now exist in rendered HTML.
Click the routes manually on desktop and mobile, including navigation that changes at breakpoints.
Verify that targets resolve directly, remain indexable where intended, and declare the expected canonical.
Compare depth, unique contextual inlinks, dead ends, and broken destinations against the baseline.
Record the implementation and validation dates in the worksheet.

Use the Search Console Links report as corroboration, not as a complete crawl export. Google says the report groups pages by canonical URL, combines duplicates, limits tables, and shows a sample rather than every link. A missing row therefore does not prove that an internal link is absent.

Ranking or traffic changes can take time and can have other causes. Validate the graph first. Then compare equivalent Search Console periods for the affected pages and queries without claiming that one link edit caused every movement.

What not to do

Do not set a link quota for every page. Page roles and reader needs differ.
Do not treat a sitemap as internal navigation. It can help discovery, but it does not create a useful reader path.
Do not force every important page into the main menu. Navigation should reflect repeated sitewide needs.
Do not link every article to every service. Relevance is more useful than repetition.
Do not optimize anchors into awkward exact-match phrases. Describe the destination naturally.
Do not strengthen a page that should be merged, redirected, noindexed, or removed. Decide its job first.
Do not promise a ranking jump from a raw inlink count. Internal links support discovery, context, structure, and navigation. They do not guarantee selection or position.

Internal linking audit checklist

The crawl starts from the real public entry point and records its scope and rendering mode.
Important pages have a defined role and preferred canonical URL.
Orphan candidates are separated from reachable but underlinked pages.
Depth is interpreted by page job, not by a universal click threshold.
Contextual routes move readers between hubs, tasks, services, proof, and support for a clear reason.
Anchors identify the destination or make its purpose clear from nearby context.
Internal links resolve directly without unintended errors, redirects, hosts, or canonical conflicts.
Desktop and mobile expose the important routes.
The repair batch records source, target, issue, decision, owner, and validation date.
The same crawl configuration verifies the final graph.

Evidence basis

Link behavior, reporting limits, and accessibility guidance were checked on August 31, 2026. The page-role map, routing matrix, review worksheet, and repair-priority method are FloxoLab audit frameworks.

Need the link graph turned into a repair list?

FloxoLab can crawl the site, separate real routing gaps from harmless low counts, and map a small batch of changes that readers and a second reviewer can verify.

Explore the SEO audit

Internal Linking Audit for Small Sites: Depth, Anchors, Routing