JavaScript & rendering SEO
If your site is built with React, Next.js, Vue or another JavaScript framework, what search engines and AI crawlers see can differ from what visitors see. I find the gap and fix the rendering strategy behind it.
What’s included
- Raw versus rendered HTML comparison for every key template
- Rendering strategy review: SSG, SSR, ISR, CSR, hydration and islands, matched to each page type
- Checks that titles, canonicals, robots directives, links and structured data exist in the initial HTML, not only after JavaScript runs
- Correct status codes in single-page apps, including real 404 and 410 responses instead of soft 404s
- Crawlable links (real anchor tags), URL structure, lazy loading and infinite scroll patterns
- Impact on Core Web Vitals: hydration cost, JavaScript budgets and INP
- AI crawler visibility: many AI crawlers do not run JavaScript, so key content should be in the first response
What you get
- A rendering audit per template with screenshots and diffs
- A recommended rendering strategy for each page type, and the reasoning
- Developer briefs for Next.js, Nuxt, React, Vue, Astro or your stack
- A test plan so regressions are caught in your deployment pipeline
Who it’s for
Sites built on JavaScript frameworks, teams migrating to a new stack, and any site where pages look complete in a browser but are thin, missing or slow to index in search.
Advanced technical work
- Rendering failures: blocked resources, timeouts, content behind clicks or scroll events
- Edge rendering and caching, TTFB and stale-while-revalidate for fast first responses
- Routing, hash URLs and history API patterns that stay crawlable
- Frameworks: Next.js, Nuxt, React, Vue, Astro, and server-rendered platforms such as WordPress and Shopify
How it works
- 01Compare raw and renderedFor each template I fetch the raw HTML and the rendered page, and list what only exists after JavaScript runs.
- 02Test what Google seesI use the URL Inspection tool and crawl comparisons to confirm what Google actually rendered and indexed.
- 03Choose the strategyEach page type gets the rendering approach that fits it: static, server-rendered, incremental or client-side.
- 04Brief and verifyYour developers get a precise brief, and I re-test after release and add checks to your pipeline.
What I need from you
- Your framework and hosting setup
- Access to Search Console
- A staging URL to test before release
Frequently asked questions
Can Google index client-side rendered (CSR) pages?
Usually yes, because Googlebot renders pages with a recent version of Chromium. But rendering is queued, can delay indexing, and fails more easily than server-rendered HTML. Other crawlers, including many AI ones, may not run JavaScript at all.
SSR, SSG or ISR: which is best for SEO?
All three deliver full HTML on the first request, which is what matters. SSG is fastest and simplest for content that changes rarely, SSR suits personalized or frequently changing pages, and ISR combines static speed with periodic refresh. The right mix depends on your page types.
Is dynamic rendering a good fix?
Google describes dynamic rendering as a workaround, not a long-term solution. I prefer moving to server-side or static rendering, and use dynamic rendering only as a temporary bridge.
Do I need to rebuild my site to fix JavaScript SEO?
Often not. Many issues are fixed by rendering key routes on the server or at build time, correcting status codes and moving directives into the initial HTML, without a full rebuild.
How do you check what AI crawlers see?
I fetch pages the way a non-rendering crawler does, from the raw HTML, and check that the key content, links and structured data are present there.