When Google finds the homepage but not deeper pages, requesting indexing repeatedly is rarely the first useful move. Test whether each route exists independently, can be discovered through real links, returns useful content, declares itself correctly and appears in the canonical sitemap.
First confirm what “not indexed” means
Use Search Console URL Inspection for a small representative set: one deeper page you expect to index, one recently published route, one route with dynamic data and one nonexistent URL. Record the user-declared canonical, Google-selected canonical when available, crawl state and whether indexing is allowed.
Do not use a general site: search as the only evidence. It can help with spot checks, but it is not a complete inventory of Google’s index. Separate the following outcomes:
| Observed state | What it suggests | Next check |
|---|---|---|
| URL unknown to Google | Discovery or recency issue | Internal anchors and sitemap membership |
| Discovered, not indexed | Google knows the URL but has not selected it | Content value, duplication, canonicals and crawl evidence |
| Crawled, not indexed | The URL was fetched but not retained | Rendered content, quality, duplication and soft-error signals |
| Duplicate / alternate canonical | Signals point to another URL | Canonical tags, redirects, internal links and sitemap consistency |
| Blocked or noindexed | An explicit control prevents the intended state | robots.txt, meta robots and X-Robots-Tag |
Cause 1: deeper routes are not linked with crawlable anchors
A homepage can be found through external links, a domain submission or a sitemap while deeper routes remain orphaned. Important URLs should be connected through ordinary <a href="..."> elements from hubs, navigation and contextually relevant pages.
- Inspect the rendered navigation and card grids for actual anchor elements.
- Check whether buttons use only JavaScript click handlers or router-specific attributes without an
href. - Confirm links point to canonical route URLs rather than preview hosts, fragments or tracking variants.
- Measure click depth from the homepage and identify orphaned sitemap URLs.
Cause 2: routes work in-app but fail on direct requests
Client-side navigation can make a route appear functional after the application loads even when a fresh request returns the homepage shell, a host-level 404 or a rewrite with no route-specific content. Open each route in a private window, refresh it and inspect its HTTP response.
Expected real page
Stable URL, appropriate 200 status, route-specific content, metadata and links.
Common SPA fallback
Every path returns the same shell and depends on an API request to decide whether content exists.
Common hosting failure
Deep links work through navigation but refreshing returns a platform 404 because rewrites are incomplete.
Common soft 404
A nonexistent route returns 200 with an empty view or “not found” message.
Cause 3: child pages point their signals back to the homepage
Template defaults can cause every route to reuse the homepage canonical, title, description or robots directives. Inspect the final document for several child routes and compare exact values.
- Each intended indexable page should normally declare its own canonical URL.
- Redirects, canonical tags, internal links and sitemap entries should converge on the same host and path.
- Remove accidental
noindexfrom public templates; do not depend on JavaScript to remove an original noindex directive. - Check HTTP
X-Robots-Tagheaders as well as HTML meta tags.
Cause 4: the sitemap contains only the homepage—or the wrong URLs
A sitemap is an important discovery input, particularly for new or recently moved sites, but it does not replace internal links or guarantee indexing. Include fully qualified canonical URLs that return useful 200 pages. Exclude preview URLs, redirecting paths, error pages and duplicate parameter states.
After deployment, request the live sitemap from the production domain and compare it with the intended route inventory. Do not assume a framework file exists merely because the source repository contains a sitemap function; verify its public output.
Cause 5: deeper pages render as empty or near-duplicate output
A child route may return 200 but deliver only a root container until JavaScript and API data load. Compare View Source with the rendered DOM and test whether critical resources are blocked, slow or failing. Google may treat an empty or error-like 200 page as a soft 404.
Also compare the useful main content across routes. Changing only a heading while reusing nearly identical thin text can produce technically accessible pages that still do not warrant separate index entries. Fix the content model instead of creating more routes.
The route-by-route diagnostic workflow
- Create an intended URL inventory. List the canonical homepage, hubs, detail templates and representative dynamic routes.
- Trace discovery paths. Confirm each important URL has at least one crawlable internal anchor from a discoverable page.
- Request routes directly. Record final URL, redirects, status, headers and initial HTML for real and nonexistent routes.
- Compare source and render. Check H1, main content, links, title, description, canonical and robots directives.
- Audit the sitemap. Compare canonical route inventory with live sitemap entries and response statuses.
- Inspect Google’s state. Use URL Inspection for a small sample and record the exact coverage reason and canonical selection.
- Fix the demonstrated layer. Repair routing, anchors, signals, rendering or content quality rather than requesting indexing blindly.
- Submit and monitor once. Request recrawl for a few corrected URLs or submit the sitemap, then allow time and track changes.
Where the failure usually lives in AI-built stacks
The same symptom can originate in different layers. Cursor is an editor, v0 often publishes a generated Next.js project to Vercel, Replit supports several deployment types, and other builders manage routing differently. Test the deployed output instead of inferring behavior from the builder name.
For the cross-platform rendering model, read JavaScript SEO for AI-built websites.
Common questions
Should I request indexing for every missing page?
Fix demonstrable route, discovery, canonical, rendering or content problems first. Google states that requesting a crawl does not guarantee inclusion, and repeated requests do not make crawling faster.
Can a sitemap fix orphan pages?
It can help discovery, but internal links remain important for discovery, context and site structure. A sitemap also does not guarantee indexing.
Why does every route show the homepage title in Google?
Check whether child routes resolve unique metadata and canonicals in production. Also check whether every route returns the same HTML shell or Google selected the homepage as canonical.
How long should indexing take after a fix?
There is no fixed time. Google says crawling may take from days to weeks, and inclusion is not guaranteed. Record the change date and monitor exact URLs instead of promising a deadline.
Primary documentation reviewed
- Google: Link best practices
- Google: JavaScript SEO basics
- Google: Build and submit a sitemap
- Google: Ask Google to recrawl URLs
- Google: Canonicalization
Check the affected routes before changing architecture
Use the manual checklist to compare source and rendered signals, review the diagnostic method, or request technical triage for the production site.
Run the manual checklistReview the methodology