A non-indexable page inlinks finding means an indexable page has a discovery-path problem. It may return a clean response and deserve to rank, but the site is asking crawlers to reach it through pages that are noindexed, blocked, or consolidated elsewhere.
The practical fix is not to make every source page indexable. First decide whether the destination is important, find its last reliable indexable path, repair the template or content source that broke that path, and prove the change in a focused recrawl. That makes this a narrower job than a broad internal links for SEO audit: the question is whether an important page has an indexable route into the site graph at all.
What This Crawl Finding Actually Means
Screaming Frog flags this issue when an indexable URL receives inlinks only from non-indexable pages, including pages with noindex, pages canonicalized elsewhere, and pages disallowed by robots.txt. Its issue documentation treats that as a discovery and signal-risk pattern, not proof that the destination cannot rank.
That distinction matters. A destination might still be listed in a sitemap, receive external links, or have been crawled in the past. But a page that matters to users should not rely on uncertain paths for ongoing discovery. The first job is to decide whether the page deserves a normal, indexable internal route.
| Finding | What it can mean | First decision |
|---|---|---|
| One editorial page is linked only from noindexed pagination | The page may lack a durable route from the indexable content graph | Add a contextual or hub link from an indexable page if the destination is important |
| A product or category is linked from canonicalized filters only | The template may point users toward a disposable variant instead of the canonical path | Repair the shared link target and verify the canonical destination receives the inlink |
| A utility page is linked only from blocked sources | The issue may be intentional if the page should not be discoverable | Confirm that the destination really belongs outside search and navigation |
| Hundreds of pages share the pattern | A shared navigation, CMS, or localization rule is likely at fault | Fix the owning rule, not one observed URL |
Decide Which Destination Pages Need an Indexable Path
Start with the destination URL, not the source warning. A page needs an indexable route when it is meant to be a canonical product, category, resource, editorial guide, or other page that people and search engines should be able to discover repeatedly.
Use a short page-purpose check:
- Confirm the final status, selected canonical, indexability state, and intended search job of the destination.
- Check whether the destination is included in the XML sitemap and whether its canonical URL is the version you expect users to reach.
- List all incoming links and classify their sources as indexable, noindexed, canonicalized, robots-disallowed, redirected, or erroring.
- Decide whether the destination needs a direct path from a topic hub, navigation component, category, related-content module, or relevant editorial page.
- If it does not need to be discoverable, document that policy instead of adding a link merely to silence the report.
This is related to an orphan pages workflow, but the diagnosis is different. An orphan page can have no discovered internal inlinks at all. Here, a crawler has found inlinks, but every known source is outside the indexable path you want important pages to depend on.
Trace the Last Indexable Path
The useful question is not simply “which page linked here?” It is “where does a crawler last have an indexable, intended route to this destination?” Work backward from the destination until you find the last healthy page in the path.
Record the evidence in a small table before changing templates:
| Evidence field | Why it matters | Owner question |
|---|---|---|
| Destination URL and page type | Establishes whether the page should receive a durable discovery route | Is this page supposed to be a canonical search and navigation destination? |
| Every inlink source | Separates one accidental source from a sitewide pattern | Which sources are indexable, and which are intentionally non-indexable? |
| Source indexability reason | Avoids treating noindex, robots, canonicalization, and redirects as the same failure | Is the source policy correct, or is that policy itself broken? |
| Link origin | Points to a CMS field, template, hub, breadcrumb, filter, or editorial module | What shared rule produced the only links? |
| Candidate indexable source | Turns the finding into a concrete repair | Where should a user naturally encounter this destination? |
Google's link best practices are a useful implementation check: important links should resolve through normal anchor elements with usable href values. A visually present control or a JavaScript-only behavior is not the same evidence as a reliable internal path.
Repair the Link Source at the Right Level
Once the destination needs an indexable path, choose the smallest shared repair that creates it. The correct action depends on why the existing sources are non-indexable.
| Source pattern | Keep or change the source policy? | Better repair | Validation |
|---|---|---|---|
| Noindexed pages are intentionally excluded | Keep the noindex policy | Add a contextual, hub, or related-content link from an indexable page | Recrawl shows the destination has at least one intended indexable source |
| Canonicalized filters point to a category | Keep disposable filters consolidated | Update modules so they link to the canonical category or product directly | Inlinks and canonicals converge on the selected representative |
| Robots-disallowed URLs are exposing the only links | Review the crawl boundary separately | Surface the destination from an allowed page; do not use robots changes as a link fix | Crawl can fetch the source of the intended route and follow the destination link |
| Redirected or erroring pages own the link module | Change the component or CMS reference | Replace the stale target in the shared module, then test representative pages | Final links resolve directly to the selected destination |
| A page is non-indexable by mistake | Fix the indexability defect before relying on its links | Resolve the directive, canonical, status, or rendering issue and then recrawl | Source becomes indexable only when that aligns with the page policy |
When a source page is noindexed, remember that a crawler needs to access the page to see the directive at all. Google's noindex guidance makes that boundary explicit. Do not combine robots, noindex, canonical, and internal-link changes without naming the page policy each control is meant to enforce.
If the nominated canonical target itself cannot be indexed, follow the separate non-indexable canonical repair workflow first. In that case, repairing an inlink alone would strengthen a path toward the wrong representative.
Validate the Repair in Crawl Data and Live HTML
One changed link is not the end of the work. Verify that the new route is present in the delivered HTML, points to the intended canonical URL, and appears across the full template or content group that caused the finding.
Use this closure checklist:
- The destination returns the expected final response and remains indexable under its intended policy.
- At least one relevant indexable page now contains a normal link to the selected canonical destination.
- The new link is visible in the HTML that users and crawlers receive, not only in a private CMS preview.
- Canonical, robots, noindex, redirect, sitemap, and link signals no longer contradict the intended route.
- A focused recrawl shows the indexable source, the destination, its crawl depth, and any remaining non-indexable source patterns.
- The team records the template, module, or editorial owner so a later release does not recreate the broken path.
Searvora's SEO Spider Crawler fits this evidence loop when a team needs to group crawl, indexability, canonical, sitemap, and page-structure signals into an owner-ready fix queue. Use the crawl to identify the affected pattern, then make the recrawl condition part of the release acceptance criteria.
Keep This Issue Separate From Nearby Link Problems
Similar labels can lead to the wrong repair. Keep the scope tight so the next action matches the evidence.
| If the finding is | The core question | Better next action |
|---|---|---|
| No internal inlinks at all | Can the crawler discover this page from any internal source? | Use an orphan-page workflow to decide whether to link, merge, redirect, noindex, or retire it |
| Follow and nofollow links conflict | Do templates disagree about whether a destination belongs in the crawl path? | Trace the shared link policy and repair the conflicting relationship |
| Canonical target is non-indexable | Is the selected representative eligible to be indexed? | Repair the target, source rule, and canonical relationship before reinforcing links |
| Only non-indexable pages link to an important destination | Where is the last intended indexable path into this page? | Add or repair a normal link from an appropriate indexable source, then recrawl |
The durable outcome is not a lower issue count. It is a site graph where every important page has an intentional, indexable discovery path and every exception has a documented policy.