JavaScript SEO Services
JavaScript decisions made during a build are cheap. The same decisions revisited after launch are expensive, and some of them are close to unfixable.
JavaScript SEO covers how search engines and AI crawlers crawl, render, and index content that is generated by JavaScript rather than served in the HTML. On React, Vue, Next.js, Nuxt and custom builds, the rendering method decides what gets found, and it is decided before a line of content is written.
I work as a freelance SEO consultant with over 10 years of experience, including work on JavaScript sites. The work is advisory. I diagnose what is happening, write recommendations your developers can act on, and provide the content and structure that goes with them.
Your development team implements. I do not touch your codebase, and I would be careful of anyone who offers to on a first engagement.
Why JavaScript Sites Get Missed?
Search engines treat rendering as a separate stage from crawling, and that gap is where JavaScript sites lose visibility.
A crawler requests the page and receives the HTML the server sent. If the content, links, and meta tags are not in that HTML, they do not exist yet as far as that request is concerned. The page then waits to be rendered, which costs the search engine significantly more resources than reading plain HTML.
For a small site, this usually resolves. For a large one, it means slower discovery of new pages, inconsistent indexing, and a crawl allowance spent on rendering rather than on finding your content.
The failure is rarely total. That is what makes it hard to spot. Pages get indexed, just fewer of them, later, and with less of their content understood than you would assume from looking at the site in a browser.
Rendering Methods and What Each Costs You
The rendering method is the single most consequential SEO decision in a JavaScript build.
- Client-side rendering sends a near-empty HTML shell and builds the page in the browser. It is the cheapest to develop and the worst for search. Everything depends on the crawler rendering the page, and not all of them will.
- Server-side rendering builds the HTML on the server for each request. Crawlers get the content immediately. It costs more in infrastructure and adds complexity around caching, which is where most SSR implementations go wrong.
- Static generation builds pages at deploy time. It is the strongest option for search and the most restrictive for content that changes often.
- Incremental regeneration, as in Next.js, rebuilds static pages on a schedule or on demand. For most content sites this is the sensible middle ground.
- Hybrid setups apply different methods to different routes. This is where most real projects end up, and where problems hide, because one route being server-rendered tells you nothing about the next one.
Frameworks matter less than the configuration. Next.js, Nuxt, SvelteKit and Astro all support server rendering. A React or Vue single-page app without a meta-framework usually does not, unless something was added specifically to handle it.
Planning a New JavaScript Build
This is the cheapest point at which to involve anyone in SEO, and the one most often skipped.
The rendering decision is made in the first week of a project and locks in what is possible for years. Changing it afterwards is a rebuild, not a fix.
Routing and URL structure sit in the same category. Whether pages have real URLs, whether those URLs are readable, whether filtered and paginated states are addressable at all. Retrofitting URLs onto a finished application means redirects, re-crawling, and a period of instability nobody budgeted for.
Asset hosting is the one people do not see coming. Serving images from a separate subdomain is convenient for the development team and treats those images as a separate property, which affects how they are reported and attributed. Consolidating them later means redirecting every image and waiting for a full re-crawl.
None of these are difficult decisions. They are just permanent ones, and they are made by people optimising for build speed rather than for what the site needs to do afterwards.
JavaScript SEO Issues Found in Almost Every Audit
Most of these are invisible in a browser and obvious in the raw HTML.
A gap between raw and rendered HTML
The first thing to check on any JS site. Compare what the server sends against what appears after JavaScript runs, and the size of that gap is the size of your problem.
Links that are not links
Navigation built on click handlers rather than anchor tags with href attributes. Crawlers follow hrefs. They do not click things.
Meta tags injected by JavaScript
Titles, descriptions, and canonicals written after page load are unreliable, and canonicals especially so.
Hydration mismatches
Server HTML and client JavaScript disagreeing, which can replace or remove content after load and is hard to detect with standard SEO tools.
Soft 404s on missing routes
Content that no longer exists returning a 200 status rather than a 404, so search engines index pages that say nothing.
Infinite scroll with no addressable URLs
Content that exists only after scrolling, on a route that cannot be linked to, is content that cannot rank.
JavaScript or CSS blocked in robots.txt
Blocking the resources needed to render the page prevents rendering entirely. Still common, usually left over from an old configuration.
Assets served from subdomains
Images and media treated as belonging to a different property than the site they appear on.
JavaScript and AI Crawlers
This is the part that has changed, and most advice has not caught up.
Google renders JavaScript. It has for years, imperfectly but reliably enough that client-side rendering has been survivable. The crawlers behind AI search products largely do not. They request the page, read the HTML the server returns, and move on.
That means a client-rendered site can be indexed by Google and effectively blank to an AI assistant summarising your market. Everything that makes the page useful is in a script that never runs.
If AI visibility matters to your business, server-rendered HTML stops being a technical preference and becomes a requirement. It is also the clearest argument available for fixing a rendering problem that has been tolerated for years on the grounds that Google seems to manage.
How the Engagement Works
There is no standard package. Every proposal is written after I have looked at the site or the build plan.
For an existing site, the work starts with a diagnosis. I compare raw and rendered HTML, check what is actually being indexed against what should be, review the rendering setup route by route, and identify which problems are costing you and which are noise.
For a planned build, it starts earlier and costs less. The conversation is about rendering strategy, URL and routing decisions, asset hosting, and what the site needs to be able to do once it exists.
Either way, what you receive is recommendations your developers can act on, with the content and structure that goes alongside them. Specifications rather than complaints. Where a fix has options with different costs, the proposal explains them so your team can choose what fits the release cycle.
Only what the diagnosis flags makes it into the proposal. Where something is not worth doing, the proposal says so and leaves it out.
Frequently Asked Questions
No. I diagnose, specify, and provide content and structure. Your developers implement. On JavaScript projects that separation matters, because the fixes sit inside your codebase and your release process.
It is the best time. Rendering method, routing, and asset decisions are cheap now and expensive later. Most of what I find on existing sites traces back to a decision made in the first fortnight of a project.
Largely, yes. That is a different question from whether it handles yours efficiently, and a different question again from whether AI crawlers handle it at all. Most of them do not execute JavaScript.
Open your page, view the raw source rather than the inspector, and search it for a sentence you can see on screen. If the sentence is not there, a crawler did not get it on the first pass either. That is the crude version of the first check I run.
React, Vue, Angular, and the meta-frameworks built on them including Next.js, Nuxt, SvelteKit and Astro. The framework matters less than how rendering is configured within it.
Ready to Find Out What Search Engines Actually See?
Most JavaScript sites look fine in a browser. That is the problem, because the browser runs your JavaScript and a crawler might not.
Hiring a JavaScript SEO expert should start with someone comparing what your server sends against what your users see.
Send me the URL, or the build plan if you have not started yet. I will tell you what I find.