Page that very few other pages link to

This is advice, not a defect. It reports a page that fewer than three other pages of the same site link to.

An internal link is how a reader finds a page without knowing its address, and how a search engine decides the page matters enough to crawl again. A page with one link pointing at it is reachable, but only just: it depends on that single page continuing to exist, continuing to carry the link, and being found itself.

For a page to pass this check:

• At least three other pages of the site link to it.

Example: a product is linked only from its category listing. The listing is paginated, the product drifts to page 7, and the one route to it is now seven clicks and a click-through away. Three links — from the category page, from a related product, and from a buying guide — make it findable from three directions.

A page's link to itself does not count. Almost every page links to itself somewhere: a logo pointing home, a breadcrumb ending on the current page, an in-page anchor to a section. None of those is another page choosing to point here, so none is counted — on this check, in the Inlinks column of the Pages table, or in the Links report.

Nor does a link from a page this scan did not cover. A page your URL allowance would not stretch to, or one your own exclusion rules dropped, is not part of the report and cannot vouch for another page. The orphan-pages check has always counted that way; this one matches it, which is what stops the two ever saying different things about the same page.

Three is a rule of thumb, not a rule. Nothing in any search engine enforces it. A page linked twice from the right places — its section index and a related article — does better than one linked ten times from a footer. That is why this is a suggestion: it shows you a page and lets you decide, and it never deducts from your health score.

A page nothing links to at all is a different finding. That is reported as an orphan page, which has a different fix: an orphan is usually a page the site forgot, while an under-linked page is one the site knows about and mentions rarely. The two never fire on the same page.

When this check says nothing. If a scan stops at its page limit, the pages beyond the limit were never fetched and their links were never read — so a page could look under-linked purely because the crawl ran out of budget before it reached the pages that link to it. The same applies if the step that assembles the link graph did not finish. The check refuses to judge such a scan rather than reporting a result it cannot stand behind.

• Crawl frequency follows links. Search engines rediscover a page by encountering links to it. A page pointed at from one place is revisited less often than one pointed at from several, so its updates take longer to be seen and a change to its title or price can sit unnoticed for weeks.

• Internal links are how authority moves around a site. Whatever standing a page has, it passes along its links. A page receiving one internal link receives one page's share; the same page linked from a section index, a related article and a guide receives three, from three different contexts. This is the one ranking factor a site controls entirely on its own.

• Anchor text is a description written by somebody else. Each inbound internal link is another sentence about what the page is for. Three links usually mean three phrasings — "our refund policy", "returns", "how to send something back" — and a page with one link has one.

• A single link is a single point of failure. Delete the linking page, restructure the navigation, or paginate a listing, and a page linked once becomes a page linked none: an orphan, reachable only by somebody who already knows the address.

• AI search and answer engines follow the same routes. Assistants that crawl a site to answer questions about it discover pages the way a search engine does. A page reached from one place is one a summariser is likelier to miss entirely.

• User experience. A reader on a related page should be able to arrive here without going back to the navigation or using search. A page linked from three relevant places is a page three journeys can reach.

Effect on the health score

None, by design. This is a suggestion, so it carries no severity and deducts nothing however many pages it names. Three inbound links is a convention rather than a requirement, and a threshold with no fault behind it must not move a score. It appears in your report so you can look at the pages and decide which of them genuinely deserve another link.

Work through these in order. The first two fix most of what this check reports.

1. Link it from the index it belongs under. Every page belongs to a section: a category, a topic, a hub, a documentation group. If the section's own index page does not link to it, that is the missing link, and it is the one a reader looking for the page would try first.

2. Link it from the pages a reader would already be on. Two or three related pages, linked from inside the body text where the subject actually comes up. Body links are worth more than a list at the bottom, because the anchor text is written in context and describes the destination.

3. Check whether it deserves a navigation entry. If the page matters to most visits, put it in the main or footer navigation. Do not do this for many pages: a navigation that lists everything describes nothing, and the sitewide link stops being a signal. This is also what the "too many internal links on one page" check exists to catch.

4. Give the link words that name the destination. "Our refund policy" tells a reader and a search engine what is at the other end; "click here" and "read more" tell neither. Vary the phrasing across the three links rather than repeating one string.

5. Look at pagination and filtering. A page reachable only from page 7 of a listing is effectively linked from nowhere a crawler visits often. Add a category, a tag index, or a "related" block that surfaces it directly.

6. Decide honestly whether it should exist. Some pages are reported here because nobody has anything to say about them. Merging a thin page into a fuller one, or removing it and redirecting, is a legitimate fix and often the right one.

When to leave it alone

• A page that is deliberately peripheral. A terms page, a one-off campaign landing page, or an author bio does not need three routes in.
• A page you intend to be found from outside. A press release or a page reached from an email campaign is linked from elsewhere on the web; internal linking is not what carries it.
• A brand-new page. It has not been woven in yet. Come back to it.

Nothing about this check is enforced by a search engine, and it deducts nothing. It is a list of pages your site rarely mentions — some of those are oversights, and some are correct.

Example 1: A page linked from three places

Scenario: A refund policy on a shop.

Passes because: three different pages point at it, each from a context where a reader would want it, and each with words that name the destination.

/help                 → "our refund policy"
/checkout             → "returns and refunds"
/blog/what-to-do-...  → "how to send something back"

Inlinks: 3

Example 2: A product reachable only from a paginated listing

Scenario: A catalogue of 400 products, listed 20 to a page. This product sits on page 7, and nothing else mentions it.

Fails because: one link points at it, from a page that is itself several clicks down and changes every time the catalogue does.

/category/kettles?page=7  → "Stainless 1.7L kettle"

Inlinks: 1

Corrected version: the product gets a route from three directions, none of which moves when the listing is reordered.

<!-- /guides/choosing-a-kettle -->
<a href="/products/stainless-17l-kettle">the stainless 1.7L kettle</a>

<!-- /products/glass-15l-kettle, in the related block -->
<a href="/products/stainless-17l-kettle">Stainless 1.7L kettle</a>

<!-- /category/kettles, in a "popular" block above the pagination -->
<a href="/products/stainless-17l-kettle">Stainless 1.7L kettle</a>

Inlinks: 3 (plus the paginated listing)

Example 3: A page that links to itself, and why it does not count

Scenario: An article linked from one other page. Its own header carries the site logo linking home, its breadcrumb ends on itself, and a "back to top" anchor points at #top — which is the same address as the page.

Reported as one inlink, not two. The self-link is the page mentioning itself, not another page choosing to point here. Counting it would let a page linked once read as linked twice and quietly suppress the finding.

/blog/index               → "The invisible handshake"   (counted)
/blog/the-invisible-...   → "#top" on itself            (not counted)

Inlinks: 1

Example 4: A page reported that is correct as it is

Scenario: /spring-sale-2026, a campaign landing page. It is linked from the blog post that announced the campaign and from nowhere else, because everybody else arrives on it from an email or an ad.

Reported, and correct as it is. The page is not meant to be woven into the site, its traffic comes from outside, and it will be retired in six weeks.

This is what makes the check a suggestion rather than a defect: it cannot tell a campaign page from a product nobody remembered to link. It shows you both and deducts nothing for either.

1. Records every internal link as it walks the site. For each page it fetches, PixyScan reads the anchors that point at other pages of the same site and stores each one as an edge from that page to that address.

2. Waits until the crawl has finished before counting anything. A link is only a countable edge once both ends are pages the crawl knows about, and a page's inbound links are usually seen while that page is still ahead of the crawl. Links pointing at a page that has not been fetched yet are held, and resolved once the crawl finishes — so the count is the site's link graph rather than the order the crawl happened to walk it in.

3. Counts, for each page, how many OTHER pages link to it. One count per pair, so a page that links here from four places in its own template counts once. A page's link to itself — a logo, a breadcrumb, an anchor to a section of the current page — is not counted at all, and neither is a link written by a page this scan did not cover: one the URL allowance would not stretch to, or one the site's own exclusion rules dropped. The orphan-pages check counts the same way, which is what keeps the two from ever disagreeing about a page.

4. Reports a page linked from one or two others. Three passes. Two is reported, with the actual number and the pages that link there on the finding.

5. Says nothing about a page linked from none. A page nothing links to is the orphan-pages finding, decided separately and against different evidence. The two checks share a boundary at exactly one inbound link and never both fire on the same page.

6. Ignores addresses that are not pages. An address that redirects is a signpost rather than a page, and nobody needs to link to it; a page that answered 4xx or 5xx is already reported as a broken page; and a URL the scan skipped or the site's own exclusion rules dropped is not part of the report.

7. Refuses the question when the crawl stopped early. If the scan reached its page limit, the pages beyond it were never fetched and their links were never read — so a page could appear under-linked purely because the crawl stopped before reaching what links to it. In that case no page is reported and the reason is recorded, rather than returning a clean result.

8. Refuses it again if the link graph is not finished. Resolving the held links is a step of its own, and a step can fail. Any link still waiting means the graph is incomplete, so the question is not answered at all — a page that looks unlinked because a step failed is worse than no answer.

9. Names the pages that do link there. The finding lists them with the anchor text each used, because the useful question is not "how many" but "where the existing links come from, and where the next one belongs".

Storage Level

Page Level

Database Table / Prisma Model

PageInternalLink, completed after the crawl from PendingInternalLink. The finding itself is stored on audit_issues.details.

Fields Used

Fields Used — PendingInternalLink

The table that makes the count a count rather than a floor. A link whose target has not been fetched yet cannot be stored as an edge, because an edge points at a page row that does not exist yet; it is held here with the target's address and resolved after the crawl.

Stored Fields on the finding

Detection Dependencies

• Internal Links — the whole finding is read off the completed link graph
• HTTP Response — the status code that decides whether the row is a page at all
• Scan configuration — the page ceiling, which decides whether the question can be answered at all