JavaScript site indexing: so that the search engine sees the same thing as a human
JavaScript site indexing breaks down in one place: the bot takes the first response from the server, and there is no content in it yet — it will be collected by the browser already on the device. Next, the address becomes a queue for the execution of scripts, and while it is there, the page is not displayed. We take two documents—the one that comes to the search agent and the one that comes to the browser—and boil them down to the same content. The method is chosen after the measurement, and not before it: prerendering, preliminary generation and server rendering differ in the cost of support several times.
working days depending on the chosen return method
free inspection of what the bot receives, 2-3 working days
Before the estimate
the bot and the person receive the same content — otherwise it is already a risk of sanctions
A strict condition
mention in the answers of AI-assistants: the selection rules are not published by any vendor
What we do not promise
Who it's for
Situations where this service delivers results
Scenario 1 of 5
The site opens normally, but it is almost absent in the search
Classic layout for the application interface. A human comes in and sees a directory, a bot comes in and sees an empty container with a script attached. In Search Console, such addresses usually lie in the status "scanned, not currently indexed" - and this is not a penalty, but simply the absence of text that could be indexed.
We'll review your situation in a free audit
Scenario 2 of 5
The content of the page comes as a separate request after loading
The description of the service, the characteristics, the price are drawn from the API already after the markup is given. For the visitor, it is a quarter of a second, for the first response of the server - emptiness. This is tested in a minute: query the address without scripting and see if the response body has your header.
Scenario 3 of 5
Navigation is done on event handlers, not on links
The button that changes the route programmatically does not exist for the bot: it searches for href and finds nothing. The site can have a thousand pages, and the bot will reach four, to which ordinary links from the header lead.
Scenario 4 of 5
It is important for you that content is read not only by search engines
Assistants and AI search modes act as their own agents and mostly do not execute scripts — they see the same thing as the bot in the first answer. Here there is a limit: we ensure readability, we do not promise a mention in someone's answer, because no one publishes the selection rules, and the volume of transitions from there is still small.
Scenario 5 of 5
The developer says that Google does everything, and formally he is right
Google is really scripting. The question is when and how full: the second pass is put in a queue, the term of which is not published and does not depend on you. On ten pages it is not noticeable, on several thousand it is very noticeable.
Cases
Tasks and results in numbers — all metrics measured by us
clinic of plastic surgery and aesthetic medicine
Task
The interface is made as a JavaScript application. It was necessary that the search engine and assistant agents received a page with text, and not an empty shell.
Solution
Search agents are given a fully assembled document; medical markings, doctor's data and breadcrumbs lie in the primary answer; policies for AI-crawlers are placed in separate files.
Result
The browser receives a 3.0 KB shell without title and description in 198 ms, the search bot receives a 126 KB assembled document (24 KB in compressed form) in 145 ms to the first byte and 178 ms to the full document; page "about us" - 86 KB. Sitemap for 89 addresses, 10 types of structured data, including MedicalClinic, Physician and BreadcrumbList. llms.txt at 22,810 bytes, robots.txt closes the training agents and lets the ones driving live traffic. Defect found: the built-in tag manager snippet is self-blocking - the exit condition compares the ID with itself, so the container is not loaded at all, and there is actually no analytics on the site. Discrepancy: Next.js is declared in the portfolio, React and Vite are actually. Measured on 07/31/2026.
Ukrainian manufacturer of non-combustible wall panels
Task
Make it so that the product characteristics are found in the search without calling the manager.
Solution
The site delivers the finished document from the server; data about the organization, address, quantitative characteristics and search script are present in the initial response.
Result
164 addresses in the site map, 164 unique - not a single duplicate. The first response is 244 ms on the main page and 208 ms in the product catalog, a complete document in 429 ms with a weight of 528 KB. 8 types of structured data: Organization, PostalAddress, Country, QuantitativeValue, SearchAction, WebSite, ImageObject, EntryPoint. robots.txt leaves the directory open and closes the service sections /api/, /admin/, /_next/. The stack declared in the portfolio matches the actual one - in our sample, this is rather an exception. Measurement 01.08.2026.
What's included
Complete list of work and what you get as a result
We take two responses on each type of page — for the search agent and for the browser — and show the difference in bytes and content: then the conversation goes on the document, not on feelings
We choose the method of delivery of the finished document for your application and mention that each costs not only for implementation, but also for support
We move the page title, description and canonical URL to the primary response - the output snippet consists of your text, not a random snippet
We give the structured data simply in the markup: the script inserted does not always reach the search engine
We turn the navigation into ordinary links - the bot gets a path deep into the directory without executing any script
We compare the content of the two answers line by line: it is this point that keeps the work in the safe zone
We measure the time to the finished document for the bot after implementation and fix the figure in writing
We separate in robots.txt agents that drive live traffic and those that collect data for training — the decision is yours, the implementation is ours
We compile llms.txt as a compressed content map for assistants: in the clinic site we measured, this file weighs 22,810 bytes
We put key addresses for verification in Search Console and look at the indexing report for 30 days
When this service isn't right
What's not included — so there are no surprises at delivery
Rewriting the frontend to another framework
Development of a new interface
Promises about mentions in AI assistant answers
Work with content and texts
Process steps
Transparent stages with approval at every step
Total duration:10–30 days
1
Measurement of the current state
2-3 working days
We request key addresses by various agents and put the answers next to each other: size, availability of title and description, structured data, links. The output is a document with two columns, where you can see what the bot can't get.
2
Choice of method and limits of work
1-2 working days
We fix the list of pages that should really be in the search, and the way to return them. The decision regarding AI agents is made right there: who to let in, who to limit. This is a business position, we only show the consequences of each option.
3
Implementation of the return of the finished document
5-15 working days
Agent-based prerendering or server-side rendering of routes. We start with one type of page on the test circuit and move on only when the response for the bot on it matches the content of the browser.
4
Meta tags, markup, and links
2-5 working days
The title, description, canonical address and structured data move to the primary response, navigation gets normal links. A reference from our measurement: on the panel manufacturer's website, the initial response contains 8 types of structured data.
5
Reconciliation of content and measurements
1-3 working days
We compare line by line what a bot sees and what a person sees: a discrepancy in content is no longer optimization, but a risk. We measure the time to the first byte and to the complete document for the bot, the numbers remain with you in writing.
6
Monitoring of indexation
30 calendar days
The key addresses are checked in Search Console, then we look at the report: how many pages changed their status and how quickly. A month is not a reserve of time, it is a period during which the report generally manages to react.
Free check of what the bot gets instead of your page
The check is simple and visual: we query your pages the way a search engine does, and compare the answer with what the browser sees. The difference between these two documents is the size of the problem.
What we measure
Response size for bot vs browserHow many bytes each gets. We measured a site where the browser received a shell of 3.0 KB, and the search bot received a fully assembled document of 126 KB.
Availability of content in the primary responseDoes it have a title, description, texts and links - or is it all already collected on the device.
Meta tags and markupDoes the page title, description, and structured data make it into the primary response? The markup inserted by the script does not always arrive.
Internal linksDo they exist in the markup as normal links. Navigation built on event handlers does not exist for a bot.
Behavior for AI agentsAssistants mostly don't run scripts on the page. If content is collected on devices, the site is empty for them.
Time for the finished documentHow long does it take for a bot to get a full response. In the measured case, it is 145 ms to the first byte and 178 ms to the full document — that is, the prerender can be fast.
What you get
Comparison of two bot and browser responses with sizes and content.
A list of what does not reach the search engine now.
Solution options with an explanation that each costs in support, not just in implementation.
Conversation for 30-40 minutes on the document.
Timeline: 2-3 working days
Why is it free
Because the check takes hours, and the difference in the cost of solutions is multiple. We don't want to sell server rendering where pre-rendering is enough.
What's next
Then there is an assessment of the selected option by stages. One option is always "do nothing": if the bot already receives the full document, there is no work.
Short form: your contact and site URL
Contract, act and 30-day warranty
Every project gets a written contract: scope, deadlines, amount, acceptance procedure. After delivery — act and invoice, then 30 calendar days of warranty.
Sole proprietor & bank transfer
The contractor is a registered sole proprietor. Payment by invoice with closing documents.
Rights & access — yours
Code, design and materials transfer to you after full payment. Domain, hosting, repository and analytics are registered to you.
Client portal instead of email chains
During the project you get access to a portal: contracts, invoices, acts and project status in one place.
European clients
Among our work — projects for Norway, Bulgaria, Moldova and Spain.
Verifiable numbers
Every case in the portfolio comes with a link to a live site and a technical measurement.
Audit first, then pricing
There is no price list on the site intentionally: the scope of the same work differs multiples between clients.
We say "no" when unsure
If the task isn't ours or the deadline is unrealistic — we tell you upfront.
Did not find your case?
Describe how it works on your side — we will tell you whether “JS rendering for search” fits and what it means in your situation. No brief and no call: one question, one answer.
What affects the price
Why two seemingly identical tasks are priced differently
Which method of return is right for youThe prerender sits on top of the existing application and touches only the rendering layer. Switching to server-side rendering rewrites routing and data handling. The difference between these two options is not measured in percentages.
How many types of pages should be in the searchHome, category, card, article - each type is analyzed separately: its own data, its own meta tags, its own markup. Twenty routes in the application do not mean twenty types; there are usually four to six of them, and it is this number that drives the estimate.
Where the content of the page comes fromOne request to your API — the finished document is simply assembled. Three sources, some of which respond only after user action, each has to be analyzed separately, and this is where the time starts to grow.
Who runs the frontendThere is a developer who knows the application - we give the edits and check the result. No - we enter someone else's code, and the first week goes to understanding how it is assembled.
Is there a need for supervision of the return layerThe prerender breaks quietly: it renders the old page without a single error, and it is noticed months later. We display the monitoring of this layer in a separate line, and do not hide it in the "support".
Technologies & integrations
What we build on and what it connects to
Stack
Server rendering is the cleanest option: the document is assembled on the server. The price of the question is the load that was not there before and the need for cache
Pre-generation on assembly is the fastest return, but every text change requires a rebuild. A catalog that changes every hour is not suitable
Agent-based pre-rendering — builds on top of a ready-made application in days. This is a separate layer, and it breaks quietly: it returns the old page without any error
Next.js — keeps all three modes at the route level. But moving to it from Vite is an app move, not a setup
Search Console, a URL checker, is the only place to see what Google actually got. Shows one address at a time and with delay
llms.txt and robots.txt — control agent access. They have power only over those who respect them: there is no mechanism of coercion here
Integrations
Google Search Console
Bing Webmaster Tools
GA4
Cloudflare
Ready document vs. hoping for a render queue
How this option differs from the alternative
Leave as is: Google will execute the scripts itselfOur approach
When the content becomes visible to the botafter the second pass, the term of which is not published and does not depend on youin the very first server response
Other readers of your contentmostly the scripts do not execute and see an empty containerBing, Assistants, and Agents get the same as Google
What can be seen from the browsereverything looks fine until someone requests the page as a botthe difference is recorded in a two-column document
The price of the solutionzero costs now and an unknown term for the pages to appear in the indeximplementation plus a layer that will have to accompany
What we need from you
We can't start without this — best to prepare in advance
1The website address and two or three pages that are most important to you: the measurement begins with them.
2Access to the frontend code or the developer behind it.
3Understanding which screens should be in the search: not all application routes are needed there, and extra ones are better to cut off at the start.
4Access to Search Console - without it, we can see our purpose, but we can't see what Google has done with it.
5Decisions about AI crawlers: allow, restrict or close. This is a business position, not a technical one, and it's up to the person on your side to make it.
If something is missing — let us know, we'll help you gather it or do it as a separate task.
FAQ
Most frequently asked questions — with concrete answers
Google executes JavaScript — then why all this?
Performs, but in two passes. The first takes the markup, the second puts the address in a queue for script execution, and the duration of this queue is not published. You won't notice the difference on a website with ten pages; at a few thousand, it turns into months, during which part of the catalog simply does not exist for issuance. The second part of the answer is more important: Google is not the only reader. Bing, assistant agents, marketplace parsers, and services that build link previews in Messenger mostly don't execute scripts at all.
Isn't prerendering for bots hiding content?
No, as long as the bot and the person receive the same document. It is a violation to show one text to the bot and another to the visitor; the form of presentation may differ, and this is normal. Therefore, there is a separate point of reconciliation in our stages: we compare two documents line by line and record in writing that they match. If you have a desire to push the bot additional keywords that a person will not see, it is not up to us, and not because we are careful, but because it is you who flies for it.
What to choose: server rendering or pre-rendering for bots?
Depends on the application and how much you're willing to pay for support. Server rendering is cleaner: the document is collected on the server for everyone in the same way, there is no separate layer. But it affects the routes and the work with data, and the server begins to carry a load that was not there before. The prerender is placed on top of the finished application in days and costs less - the price is that it is an additional layer that breaks without any notice: the page is given as old, there is no error, it is noticed after a month. We call both numbers, implementation and oversight, and the decision is up to you.
How to understand that the problem is precisely in rendering?
Ask the page twice — as a browser and as a search agent — and put the answers side by side. In the clinic site we measured, the browser receives a 3.0 KB shell with no title or description, and the search bot receives a 126 KB compiled document. A confusing detail: the bot responds FASTER than the browser — 145 ms versus 198 ms, because the finished document is already there, and the envelope still needs to be assembled. From the browser, everything looks perfect, and that's why the problem is found late.
In Search Console, pages with a status of "scanned, not currently indexed" - is that it?
Often yes, but not always. This status means that the bot took the address and decided not to put it in the index yet. There are two big groups of reasons: there was no content in the response (this is our case) or there was content, but it looks too similar to neighboring pages or too empty in essence. It makes a difference in a minute: see in the URL Checker exactly what the bot saw. If there is a shell without text, it is a matter of rendering. If there is text, but there is no indexing, the question is about the content, and this is a different service.
Does this affect visibility in AI assistants?
Affects the opportunity, not the outcome. Agents read what is given in the markup immediately; if it is empty, there is nothing to quote you. But we do not make any promises regarding mentions: no vendor publishes selection rules, no one has any guarantees, and the volume of conversions from there is still small compared to a normal search. It's a lead-in job with an unknown payoff, and we talk about it like that. Separately, about blocking training agents: it does not remove your content from models that have already been trained.
Will it be necessary to rewrite the site on another framework?
Most of the time, no, and we deliberately don't start there. First, we check whether your current application is able to deliver the finished document at least on the necessary routes - often it is, it's just that no one has done it. The advice we give more often than others is don't change frameworks for search. Moving from one stack to another is moving an entire application with new bugs, and next to that, prerendering on four page types feels like a week's work. Frontend rewriting is not included in this service at all.
How long does it last and when will the effect be visible?
The works themselves — 10–30 working days depending on the chosen method: pre-rendering is faster, server rendering affects the architecture, and the term there depends on how ready the application is for it. The effect in the index moves slower than work: after the address changes, they go for verification, and we just look at the report for a month. This is not our slowness - it is the speed with which the search engine goes around the site, and it is impossible to speed it up from the outside.
Send the website address and the two or three pages that are most important to you.
The response is two side-by-side server responses: the one the browser gets and the one the search agent gets, with the sizes and a list of what's missing from the second one. If everything is already in place, we will say so in the first email.
From measured cases164 addresses in the site map, 164 unique - not a single duplicate
There is no price list on the site on purpose: the same work differs several times over between two clients, and a “from” figure explains nothing in that case. First a free audit — we count your pages, duplicates and speed — then we name the sum and the deadline and fix both in the contract.