Before You Pay for a Website, Check What a Bot Sees
Contents8
You are about to approve a quote for a new website. It looks good on the designer's screen, it loads on your phone, and the price is fair. There is one check worth running before you pay, and it takes two minutes.
Fetch the page without JavaScript. If your main selling sentence and your price are not in what comes back, some readers will never see them. On 25 October 2026 we fetched nine Singapore service websites this way. Eight returned between 659 and 3,072 words. One returned six.
This is not an argument against modern website builders. Eight of nine were fine. It is an argument for one check before the invoice, because the fix is cheap before launch and awkward afterwards.
The problem: a site that looks finished and reads as blank
A website can be fully built, fully designed and completely empty to anything that does not run a browser.
The site we found had five pages in our sample. To a plain fetch, each one carried six words of visible text. Its headings, its service descriptions, its contact details were all there on screen and none of them were in what the server sent. A person sees a finished website. A reader that does not execute JavaScript sees a shell.
Who are those readers? Price comparison tools, link preview generators in WhatsApp and Slack, some archiving services, and several of the AI crawlers that surface pages inside assistant answers. We have measured what happens when a crawler is refused outright in checking the bot gets in before you buy AI visibility. This is the quieter version of the same loss: the bot gets in, the door opens, and the room is empty.
Why it happens: the page is assembled in the browser
Because the server now sends instructions rather than content, and something has to follow the instructions.
Google's own documentation on JavaScript SEO basics sets out three phases: crawling, rendering and indexing. Rendering is a separate step with a queue. Google says "Once Google's resources allow, a headless Chromium renders the page and executes the JavaScript", and about the wait: "The page may stay on this queue for a few seconds, but it can take longer than that."
So Google can read a browser-assembled page. It just does it later, on its own schedule, and only for pages it has decided to spend that budget on.
Everyone else is less generous. Google's recommendation in the same document is blunt about it: "server-side or pre-rendering is still a great idea", and the reason it gives is "not all bots can run JavaScript."
That is the whole mechanism. Your builder is probably capable of sending finished HTML. Whether it does depends on a setting, a plan tier or a template choice that nobody mentioned in the quote.
What else we saw on that one site
The rendering was not its biggest problem. Its five sampled pages each declared the homepage as their canonical URL.
A canonical tag tells a search engine which address is the real one for a piece of content. When the about page, the services page, the blog and the contact page all point at the homepage, they are each saying: do not index me, index that instead. The same five pages also served one identical title and one identical meta description.
That is not a JavaScript problem. It is a default that was never changed, and it is more expensive than slow rendering, because it asks Google to throw four pages away. If your new site arrives with every page claiming to be the homepage, no amount of content work will help until that is corrected. It belongs on the same list as the causes in why a website is not showing on Google.
We mention it because both faults came from the same source: nobody checked what the build was sending, as opposed to what it was showing.
The two-minute test before you pay the invoice
Three steps, on the staging link, before the final payment:
- Open the page source, not the page. In your browser, view the page source for the staging URL. This shows what the server sent, before your browser builds anything.
- Search it for three strings. Your main service sentence. Your price or price range. Your phone number. Use the browser's find function on the source. If all three are missing, the content is being assembled in the browser.
- Check the canonical on an inner page. Search the source of your services page for
canonical. The address next to it should be that services page, not the homepage.
If the strings are there, stop. Your site is readable and this article does not apply to you. That was true for eight of the nine sites we fetched.
If they are not, you have one question for whoever is building it: can this be served pre-rendered, or server-side rendered, for the main pages. Ask it before you pay, while the answer is a configuration task rather than a change request.
When assembling in the browser is fine
More often than owners fear. The question is which pages, not which technology.
A booking calendar, a quote calculator, a members' area, a dashboard: these should be interactive and nobody needs a crawler to read them. Build them however your developer prefers. The pages that need to arrive finished are the ones that have to be found and quoted: your service pages, your price page, your location page, your articles.
In our view the mistake is treating this as a platform argument. We have seen fast, readable sites and empty shells come out of the same tools. One setting usually separates them.
What a fix costs, and when not to rebuild
Before launch, this is usually a setting and a redeploy. After launch, it is a scoped job: typically the main service pages first, leaving interactive pages alone.
Here is the part that costs us something to write. "Your site needs rebuilding" is the easiest thing an agency can sell. It is a large invoice, it is hard for you to argue with, and it resets the clock on every promise made about the old site. We have advised against the same reflex over a bad speed score in not rebuilding over a PageSpeed number.
Our honest position: one near-empty source on nine sites is not evidence of a widespread crisis, and a rebuild is almost never the proportionate answer. If your price and your service sentence are in the source, you do not have this problem, and we would rather tell you that than sell you a project. If they are not, you need a rendering change on a handful of pages and a corrected canonical, which is work measured in days.
What you give up by running the check: ten minutes and a slightly more awkward conversation with your web developer before you pay them. What you give up by skipping it: you will not find out from your analytics, because the visitors who could not read the page never arrived to be counted.
One next step
If you are mid-quote and unsure what the source of your staging site contains, send us the staging URL and we will tell you what a crawler receives: whether your service sentence, price and phone number are in the HTML, and what each page declares as its canonical. That is a free visibility check through our contact page.
If you want the ongoing search work rather than a one-off read, our SEO, AEO and GEO programme is S$750/month with 20 articles a month, on a three-month minimum and then month to month. We do not build websites, which is part of why we are comfortable telling you not to rebuild yours.
FAQ
Does Google read JavaScript websites?
Yes, with a delay. Google's JavaScript SEO documentation describes three phases, crawling, rendering and indexing, and says a page waits in a rendering queue which "may stay on this queue for a few seconds, but it can take longer than that". It recommends server-side or pre-rendering anyway, because not all bots run JavaScript.
How do I tell if my website is assembled in the browser?
View the page source, then use find to search it for your main service sentence, your price and your phone number. The source is what the server sent. If those strings are absent from the source but visible on screen, your browser is building the page from JavaScript.
Is a drag-and-drop website builder bad for SEO?
Not inherently. On 25 October 2026 we fetched nine Singapore service websites and eight returned between 659 and 3,072 words of readable text without JavaScript. The difference between a readable site and an empty shell is usually a setting or a template choice, not the tool.
What does a canonical tag pointing at the homepage do?
It tells search engines that the homepage is the real address for that content, so the page asking should not be indexed in its own right. On one site in our sample, five pages each named the homepage as canonical, which asks Google to discard four of them.
Should I ask my web developer about rendering before paying?
Yes, because the timing changes the price. Before launch it is a configuration change. After launch it becomes a change request on a finished build. One question is enough: can the main service and price pages be served pre-rendered or server-side rendered.
Does this mean I need to rebuild my website?
Almost never. If your service sentence and price appear in the page source, this does not apply to you. If they do not, the proportionate fix is a rendering change on your main pages plus a corrected canonical, not a new site. Read how many pages a website actually needs first.