Page carrying an unusually large number of internal links

This is advice, not a defect. It reports a page that links out to more than 100 different pages of the same site.

Different pages, not different anchors: a navigation that links the same twenty destinations from three places is twenty, not sixty. What the check is about is how many ways out of the page there are, which is what divides its ranking signal and what a reader has to choose between.

There is no rule anywhere that a page may only have a hundred links. Google published a rough guideline to that effect long ago and retired it years back, and plenty of perfectly good pages — a full category listing, a site map page, a year archive — legitimately carry more. What the number is good for is spotting the pages where it happened by accident.

For a page to pass this check:

• It links to 100 or fewer distinct pages of the site. Exactly 100 passes.

Example: a product template renders a "you may also like" grid, a full category tree in the footer and a faceted filter sidebar. None of the three was designed to be a link list, and together they put 340 links on every product page.

The count is of links PixyScan recorded for that page. Because a link is only stored once its destination has been seen by the crawl, the real number can be higher than the one reported — so this check can miss a page, but a page it does report genuinely carries that many.

• Signal is divided. Whatever authority a page has to pass is shared out among the links it carries. Three hundred and forty ways out of a page means each one gets very little, including the handful that actually matter.
• Crawlers have to work through them. Every link is a URL a crawler considers. A template that adds two hundred navigational links to every page multiplies that across the whole site.
• Readers cannot use them. A hundred links is more than anyone scans. The ones a visitor came for are buried in the ones the template added.
• It usually points at something else. A page well over the line is often displaying an unpaginated list, an unfiltered category tree, or a faceted navigation that should not be linked at all — and that underlying thing is worth finding.

It is reported as a suggestion and carries no severity, so it never deducts from the health score. That is the honest grading: a threshold with no fault behind it. Crossing 100 links is not wrong, it is unusual, and the value of saying so is that it shows you where to look — not that it condemns the page.

Because it never deducts, a genuine index page with 400 legitimate links costs its site nothing. It simply appears on the report, which is where a page like that belongs.

1. Look at what is producing them. Open the page and count the sources. It is almost always one component — a footer sitemap, a category tree, a related grid, a faceted sidebar — rather than the page's own content.

2. Paginate long lists. A category with 400 products wants pages of 24 to 60, not one page of 400.

3. Cut the footer down. A footer that lists every page of the site adds those links to every page of the site. Link the sections; let the section pages link their contents.

4. Stop linking faceted combinations. Filter and sort permutations multiply without limit. Serve them behind controls that do not produce crawlable links, or keep them out of the crawl deliberately.

5. Trim "related" blocks. Three to six genuinely related links do more than thirty.

6. Leave a real index alone. If the page's job is to be a list — a site map, an archive, a full catalogue index — a large number of links is correct. Confirm that is what it is, and move on.

Example 1: An ordinary content page

Scenario: An article with body links, a short related block and a normal navigation.

Passes because: the total is well under the line.

Navigation:      18 links
Body content:     6 links
Related posts:    4 links
Footer:          12 links
Total:           40 internal links

Example 2: A product page carrying three link lists

Scenario: A template that renders a full category tree in the footer, a faceted filter sidebar and a large recommendation grid.

Fails because: the page carries 340 ways out, almost none of them chosen for this product.

Navigation:       22 links
Faceted sidebar: 156 links
Related grid:     48 links
Footer sitemap:  114 links
Total:           340 internal links

Corrected version: link section pages rather than every leaf, put the filters behind controls that do not generate crawlable URLs, and trim the grid.

Navigation:       22 links
Filters:           0 crawlable links
Related grid:      6 links
Footer:           14 links
Total:            42 internal links

Example 3: A page that should be left alone

Scenario: An HTML site map at /sitemap, listing every section and page.

Reported, and correct as it is. Being a list of links is the page's entire purpose. This is why the check is advice and deducts nothing — it shows you the page and lets you decide.

1. Counts the internal links recorded for each page. Links to other sites are not counted here — external links are a separate part of the Links report.

2. Counts one per destination. Where a page links to the same destination several times, that is one, not several. The number reported is distinct ways out of the page, never a count of anchor tags — a template that repeats the same twenty links in a header, a sidebar and a footer contributes twenty.

3. Compares against 100. More than 100 is reported; exactly 100 is not.

4. Reports the number it counted. The finding names the actual figure, so a page at 104 and a page at 1,900 are visibly different problems.

5. Says nothing about which links to remove. That is an editorial decision about the page, and the check has no basis for making it.

One limitation, stated plainly: a link is recorded only once the crawl has already seen its destination, so the stored count can be lower than the true one. This check therefore misses pages rather than inventing them — every page it reports really does carry the number shown.

Storage Level

Page Level

Database Table / Prisma Model

PageInternalLink. The finding itself is stored on audit_issues.details.

Fields Used

Stored Fields on the finding

Detection Dependencies

• Internal Links