Fixing unindexed links on single page apps

Last Tuesday, a client called asking why three months of high-end digital PR placement work hadn’t moved their core product category rankings. The client’s platform ran on a headless React setup. On the surface, the site looked slick: fast transition states, crisp UI components, and clean URL paths. But when we inspected the DOM, half of the contextual links we had built into the interface were ghosted. Googlebot simply wasn’t following them because the rendering engine never fired the nested hydration scripts responsible for drawing those links onto the page.

If you have tried fixing unindexed links on single page apps before, you know how frustrating this gets. You check your backlink reports, verify the URLs return a 200 HTTP status, and confirm your internal linking strategy looks solid in Figma. Yet, Google Search Console keeps listing target URLs under “Discovered - currently not indexed” or leaves them out of the index altogether.

Single Page Applications (SPAs) built on React, Vue, Angular, or custom client-side frameworks present a unique challenge for search engine crawlers. Traditional websites hand Google complete, fully formed HTML documents on the first HTTP request. SPAs hand Google a skeletal HTML shell, a few div tags, and a chunk of JavaScript code with instructions on how to build the page later. When that rendering process stumbles, your link graph falls apart.

Why JavaScript frameworks break link discovery

Search crawlers process traditional sites in a straight line: fetch the HTML, parse the markup, extract every <a href="..."> attribute, add those URLs to the crawl queue, and index the content.

SPAs break this linear path by introducing client-side routing and deferred rendering. Googlebot handles JavaScript through a two-wave indexing system. In wave one, the crawler fetches the raw HTTP response and parses whatever static HTML exists. If your links are injected into the DOM after client-side scripts run, those links have to wait for wave two: the rendering queue.

Wave 1 (Instant):  Fetch Server HTML -> Parse Raw DOM -> Extract Hardcoded Links
                                                              |
Wave 2 (Deferred): Queue JavaScript -> Execute Client Code -> Extract Rendered Links

The rendering queue isn’t instant. It relies on headless rendering instances that carry execution budgets, strict processing timeouts, and strict resource limitations. If your app relies on complex state management, API calls that take a second or two to respond, or client-side routing libraries that don’t output standard semantic link elements, Googlebot’s renderer may terminate execution before your links are drawn in the DOM.

Furthermore, many SPA frameworks default to non-standard navigation patterns. Developers frequently build interactive components using <div onClick={navigate}> or <a href="javascript:void(0)"> to handle routing within client-side state without triggering a full page refresh. While this creates a smooth experience for desktop users, Googlebot ignores these elements entirely. The crawler explicitly looks for standard HTML anchor tags containing absolute or relative URLs in their href attributes. Without those, link equity stops dead in its tracks.

Diagnosing unindexed links on single page apps: a step-by-step audit

Before changing backend code or re-architecting your front end, you need to prove exactly where the link extraction pipeline is breaking. Follow this step-by-step diagnostic process to find silent failures in client-side link rendering.

1. Perform a raw HTTP response check Run a simple curl request or view the raw source of your target page (Ctrl+U / Cmd+Option+U) without letting JavaScript run. Search the raw output for your key target internal links (<a href="/category/product">). If the link isn’t in the raw payload, you are relying entirely on Google’s deferred rendering wave.

2. Disable JavaScript in Chrome Developer Tools Open Chrome DevTools, press Ctrl+Shift+P (or Cmd+Shift+P on Mac), type “Disable JavaScript”, and refresh the page. Navigate through your main menus, breadcrumbs, and inline contextual content. Any link or routing element that vanishes or stops working is an unindexed link vector.

3. Inspect the live rendered DOM via Google Search Console Open GSC, enter the URL containing the unindexed links, and run a Live Test. Once complete, click View Tested Page and inspect the HTML tab. Use the search bar inside that tab to search for your target internal URLs. If the links are absent here, Googlebot’s renderer failed to execute the script responsible for inserting them.

4. Compare raw source against the rendered DOM Export the raw HTML from step 1 and the rendered DOM from step 3. Run a diff using a tool like Diffchecker or Screaming Frog’s “Compare Crawls” feature (configured with JavaScript rendering enabled vs. disabled). Identify every link component present in the rendered version but missing from the raw payload.

5. Review console execution errors and network timeouts In the GSC Live Test output, check the More Info tab for JavaScript console errors or blocked resources. If your framework relies on an internal API endpoint to populate navigation links and that API request times out or is blocked by robots.txt, the links will never render for the crawler.

6. Validate link element semantics Inspect every target link using Chrome DevTools. Confirm that the rendered element is a true <a href="..."> tag. If you see <button>, <span data-link="...">, or <a no-href>, your development framework is bypassing browser-native link structures.

Client-side routing vs Server-Side Rendering (SSR)

Fixing client-side link issues means choosing how your server delivers page structures to browsers and crawlers. The table below outlines how common SPA architecture patterns handle internal link discovery.

If your app uses pure Client-Side Rendering (CSR), you are putting full responsibility for link discovery on Googlebot’s rendering engine. When scaling an agency site or large enterprise product catalog, pure CSR leads to indexation bottlenecks.

Transitioning to Server-Side Rendering (SSR) or Static Site Generation (SSG) via modern frameworks like Next.js (for React), Nuxt (for Vue), or SvelteKit ensures that every <a href="..."> tag ships directly in the initial HTTP payload. The client-side framework still handles fast, smooth transitions once the page loads in a user’s browser, but crawlers get clean, accessible HTML instantly.

For many teams, converting an enterprise client-side application to full SSR requires massive developer effort and refactoring. If a full rebuild isn’t immediately possible, orphan page fixing for beginners offers foundational concepts on prioritizing which page paths to fix first.

Correcting framework navigation elements and DOM state issues

A common cause of link loss on single page apps isn’t the rendering engine itself—it’s front-end developers overriding standard web links. Framework developer tutorials often encourage event-driven routing patterns that inadvertently hide links from search bots.

Bad: Event-driven wrapper components

In React or Vue applications, developers frequently write components like this:

// DO NOT DO THIS FOR INTERNAL LINKS
import { useNavigate } from 'react-router-dom';

function CategoryCard({ category }) {
  const navigate = useNavigate();

  return (
    <div className="card" onClick={() => navigate(`/categories/${category.slug}`)}>
      <h3>{category.name}</h3>
    </div>
  );
}

To a user, this card acts like a link. But to Googlebot, this is an interactive <div> element with no destination. The crawler extracts no URL, passes no link authority, and adds nothing to the crawl queue.

Good: Native semantic anchors with framework routing

Fix this by using native anchor components provided by your router library, ensuring they output real <a href="..."> elements into the final markup:

// CORRECT ACCESSIBLE AND CRAWLABLE LINK
import { Link } from 'react-router-dom';

function CategoryCard({ category }) {
  return (
    <Link to={`/categories/${category.slug}`} className="card">
      <h3>{category.name}</h3>
    </Link>
  );
}

If you use Next.js, always make sure your <Link> components produce true href values. In older versions of Next.js, failing to wrap custom child components properly resulted in rendered <a> tags with missing href attributes, completely breaking crawler access.

Fixing dynamic state and tabbed interface links

Another problem area is state-driven interfaces, such as tabbed product displays, dynamic paginations, or expandable accordions. When content sections hide behind UI state hooks (useState(false)), the links inside those hidden states often don’t exist in the DOM until a user clicks the toggle button.

[User clicks Tab 2] ──> React State Updates ──> Component Mounts ──> Link Injected into DOM
                                                                          ^
                                                                 Googlebot NEVER reaches this step

To fix this issue: 1. Render all tabbed content panels directly into the DOM on initial load. 2. Hide inactive panels using CSS (display: none or visibility: hidden) rather than unmounting components from the React/Vue DOM tree. 3. Ensure every tab button uses a real deep-link URL (e.g., /product#specifications or /product?tab=specifications) wrapped in an anchor tag.

Googlebot parses CSS-hidden content and extracts the links inside it, provided those elements exist in the page HTML DOM.

Costs and tradeoffs of SPA link remediation approaches

Fixing unindexed links on single page applications isn’t free. Every solution involves technical tradeoffs, engineering overhead, infrastructure expenses, and ongoing maintenance. Understanding these trade-offs helps you choose the right fix for your agency or development workflow.

Option 1: Native SSR/SSG framework migration

• Infrastructure Cost: Higher server resource demands (Node.js runtime instances, serverless edge function execution costs).
• Engineering Effort: High. Requires converting client-only state, refactoring browser-dependent APIs (like window or document), and restructuring data fetching logic.
• SEO Impact: Excellent. Completely eliminates client-side rendering issues for link discovery and indexation.
• Maintenance Overhead: Low once operational. Built-in framework standards enforce clean HTML production across future deployments.

Option 2: Pre-rendering / Dynamic rendering snapshots

• Infrastructure Cost: Medium. Requires third-party rendering services (like Prerender.io or custom Puppeteer middleware clusters running on AWS Lambda).
• Engineering Effort: Low to Medium. Minimal changes to original front-end application code; mostly edge routing rule management via Cloudflare Workers or Nginx.
• SEO Impact: Moderate to Good. Serves fully rendered HTML to search bots, but introduces risk if cache invalidation fails or if content parity drifts between what bots and users see.
• Maintenance Overhead: High. Monitoring snapshot queues, handling cache purges, and troubleshooting edge route bypasses requires continuous oversight.

Option 3: Front-end semantic DOM refactoring

• Infrastructure Cost: Zero additional server cost.
• Engineering Effort: Medium. Audit component codebases, replace custom event listeners with semantic <a href> elements, and ensure CSS hides unselected states instead of unmounting components.
• SEO Impact: Moderate. Fixes basic crawler discovery issues, but still leaves the site dependent on Googlebot’s deferred JavaScript rendering queue.
• Maintenance Overhead: Medium. Requires developer code reviews to ensure new UI components don’t reintroduce bad routing practices.

When evaluating your budget and technical capabilities, reviewing orphan page fixing costs for small teams can help put these engineering investments into realistic agency perspective.

Realistic case scenario: fixing a headless e-commerce store

To see how these concepts work in practice, let’s look at a realistic scenario involving an e-commerce platform migration.

The scenario

A apparel brand migrated its site to a headless architecture using React on the front end and a custom GraphQL backend for product data. Over 40% of their deeper subcategory and product detail pages dropped out of Google’s index within six weeks of launch. Key category page positions dropped significantly, and revenue from organic search fell drastically.

The root cause audit

We audited the site using Google Search Console and custom crawl scripts: * Main navigation menus relied on dynamic JSON calls fetched only when a user hovered over or clicked a “Categories” dropdown button. * Deep product links on subcategory pages were rendered using <div onClick={() => router.push('/product-slug')}>. * Pagination used infinity scroll components that dynamically fetched new products via client JavaScript without updated <a href> links or clean, URL-driven pagination fallbacks.

As a result, Googlebot indexed the homepage and main parent category pages, but could not discover or crawl the links leading to deeper products.

The remediation plan

The engineering team implemented a focused, three-part remediation sprint:

1. Semantic link element overhaul: Replaced every interactive <div> and <button> navigation component with native framework <Link> tags, outputting standard <a href="/shop/product-slug"> elements into the DOM.
2. SSR for navigation trees: Re-architected top navigation and category grid components to pre-render full link structures on the server during request build time.
3. HTML breadcrumb injection: Added hardcoded server-rendered breadcrumb trails (<nav aria-label="Breadcrumb">) to all product detail and subcategory pages.

By ensuring every link existed in the initial HTML markup, Googlebot discovered and processed the entire page hierarchy within four weeks, restoring search visibility.

Testing and validating link crawlability in SPA deployments

Once you deploy front-end patches or server-side rendering updates, you must systematically verify that search engines can read your link structures. Relying on visual browser testing isn’t enough because visual browser testing executes all JavaScript instantly under ideal client conditions.

Command-Line verification via cURL

Use curl to fetch your page markup directly from your terminal. This strips away all browser execution and shows you exactly what a basic HTTP pass yields:

curl -A "Googlebot" -s https://example.com/category-page | grep -o '<a [^>]*href=["'\''][^"'\'']*["'\'']'

If this command returns an empty result or misses key target links, your application still relies on deferred client-side JavaScript execution to expose its internal link architecture.

Automated CI/CD build assertions

Prevent regressions by adding link validation assertions to your continuous integration deployment pipelines. You can write a basic Jest, Playwright, or Cypress test that checks for real HTML link elements in unrendered page responses before code reaches production:

// Example Playwright assertion testing raw HTML payload
import { test, expect } from '@playwright/test';

test('raw HTML response contains target contextual links', async ({ request }) => {
  const response = await request.get('https://staging.example.com/category');
  const htmlText = await response.text();

  // Assert anchor tags with actual destination paths exist in initial text
  expect(htmlText).toContain('href="/products/target-item"');
  expect(htmlText).not.toContain('href="javascript:void(0)"');
});

Crawl budget and link depth benchmarking

Run a local JavaScript-disabled crawl using tools like Screaming Frog or Sitebulb, then run a second pass with JavaScript rendering enabled.

Compare the total discovered link counts between the two passes. In a well-architected SPA, the link count of the non-JavaScript crawl should closely match the JavaScript-enabled crawl. If your non-JS pass discovers drastically fewer links, your application still relies too heavily on client-side rendering for its core link structure.

Comparing architectural approaches against established frameworks like those detailed in orphan page fixing vs alternatives helps ensure your testing methodology lines up with modern web standards.

Strategic recommendations: what to do this week

If you are currently managing a client or internal site suffering from unindexed single page app links, don’t try to refactor the entire codebase at once. Focus on immediate, high-impact fixes that restore crawler access to your key target URLs:

1. Audit top-tier revenue pages Run raw curl requests against your top category pages and high-value landing pages today. Identify if core contextual links exist in the raw HTML payload.
2. Convert event-driven routing elements Identify all <div onClick> and <button> navigation elements in your primary templates and replace them with semantic, native <a href="..."> anchor tags.
3. Expose hidden interface links Ensure hidden UI states (tabs, accordions, dynamic filtering drawers) leave their link elements in the DOM using CSS visibility toggles rather than unmounting components from the React/Vue component tree.
4. Implement edge snapshotting for critical paths If a full server-side rendering migration is months away, deploy dynamic rendering workers via Cloudflare Workers or a pre-rendering service to serve HTML snapshots for high-priority unindexed sections.
5. Establish deployment monitoring Add automated assertions to your build pipeline to verify that essential navigation links remain present in raw server responses before new front-end releases hit production environments.

For a clearer picture of what performance targets your team should aim for after applying these fixes, review orphan page fixing benchmarks.

If you want a streamlined system to continuously track link health, detect rendering drops, and manage internal link architecture across complex client platforms without manual crawl overhead, OptiLink provides automated auditing built specifically for modern JavaScript-heavy web applications.

Keep reading

Playbook

Broken link building, step by step: find, fix, and pitch

Broken link building works when your replacement does the dead link's job. Here is how to find dead links, verify them, match a fix, and pitch honestly.

Sofia Meyer October 9, 20262 min read

Playbook

Competitor backlink analysis that finds real opportunities

Competitor backlink analysis pays off when you sort rivals' links by how they were earned. Use the intersect, a repeatable-link test and a dated action list.

Sofia Meyer September 26, 20262 min read

Playbook

Digital PR: the most durable link building there is

Digital PR earns links from journalists through original data, timely news and expert commentary. Here's the campaign workflow and how to measure it honestly.

Sofia Meyer October 13, 20262 min read

Explainer

Dofollow vs nofollow in 2026: what still passes value

The link attributes changed, Google's treatment changed, and a lot of advice is out of date. Here's what dofollow, nofollow, sponsored and ugc actually do now.

The OptiLink Team October 10, 20262 min read