JavaScript SEO Singapore: What Google Can and Cannot Crawl

Quick answer: JavaScript SEO Singapore sites require comes down to timing. Google crawls HTML immediately but renders JavaScript later in a separate queue. If your links, content or page titles only exist after a script runs, they may be discovered slowly or missed entirely. Server rendering removes that risk.

A Singapore agency builds you a beautiful React site. It loads fast, it animates smoothly, the client is delighted, and six months later organic traffic has gone nowhere. The developer insists nothing is wrong, because when you visit the site everything is visibly there. And the developer is telling the truth about what they can see. The problem is that a search engine and a browser experience your site in two different sequences, and modern JavaScript frameworks widen the gap between them. This is not a story about Google being unable to handle JavaScript, which stopped being true years ago and is repeated far too often by people selling static site builds. Google runs JavaScript perfectly well. It just runs it on its own schedule, with its own constraints, and everything your site depends on that script for inherits that delay and that risk. This guide explains what actually happens between a crawler requesting your URL and your content entering the index, where React and Vue builds break that chain, and how to test what Google really sees. For sites where the stakes are commercial rather than cosmetic, our SEO services treat this as a build decision rather than an afterthought.

The Two Sequences: How a Browser and a Crawler Differ

When a person visits your site, their browser downloads the HTML, sees that it references JavaScript, downloads and executes that JavaScript, and the page assembles itself in front of them. Total elapsed time on a decent Singapore connection: a second or two. The visitor never perceives the stages.

A search engine does something different. It fetches your raw HTML and parses it immediately. Anything present in that raw HTML, meaning links, headings, body text and meta tags, is available instantly. Anything not present goes nowhere until a second, separate process runs your JavaScript and produces the finished page. That second process is the rendering queue.

The critical detail is that the rendering queue is not instant and is not guaranteed to be immediate. Google has said the delay is usually short, and in practice for a healthy site it often is. But “usually short” is doing real work in that sentence. For a large site, a slow site, or a site with a low crawl priority, the gap between the initial fetch and the render can stretch. During that gap, your page exists in the index as whatever your raw HTML contained, which on a default single page application build is close to nothing.

This is why the term client side rendering, usually shortened to CSR, matters. Client side rendering means the server sends a nearly empty HTML shell plus a JavaScript bundle, and the visitor’s device assembles the page. It is the default for a standard React or Vue project created without a framework on top. Server side rendering, or SSR, means the server assembles the finished HTML and sends it complete, with JavaScript then taking over interactivity afterwards. That takeover step is called hydration.

What Google Can Crawl, And What It Genuinely Cannot

Let us be precise, because vague warnings in this area have caused a lot of unnecessary rebuilds.

Google can execute JavaScript. It uses a current version of Chromium to render pages. Modern syntax, frameworks, fetch requests and DOM manipulation are all handled.

Google can find links created by JavaScript, provided they end up as real anchor elements with real href attributes in the rendered output.

Google can read content injected after load, provided that injection happens without user interaction.

Now the limits, which are the part that matters.

Google does not click, scroll, hover or type. If your content only appears after a user clicks a tab, expands an accordion, or scrolls to trigger infinite loading, the crawler will not see it. Accordion content that exists in the DOM but is visually hidden by CSS is fine. Accordion content that is fetched only when the header is clicked is not.

Google does not maintain state between page loads in the way a user session does. Anything dependent on data held in local storage or a session from a previous page will not be there.

Google will not wait indefinitely. Rendering has a practical time limit. A component that waits for three chained API calls before displaying product information is gambling with that limit.

Anything requiring a login is invisible. If content sits behind authentication, it is not indexable, full stop.

Onclick navigation is not a link. A div with an onclick handler that changes the route is invisible as a link, no matter how well it works for users. This is the single most common structural failure we find in framework built Singapore sites, and it silently removes entire sections of a site from discovery.

The Five Failures We Find Most Often in Singapore Framework Builds

Across React, Vue, Next.js, Nuxt and Angular builds locally, the same five problems recur.

One, the empty shell. View source on the page and the body contains a single <div id="root"></div>. Everything else arrives via script. This is survivable on a small, well linked site and dangerous on a large one, because every page depends on the render queue before it exists in any meaningful sense.

Two, identical meta tags across every route. In a single page application, changing the page title and meta description on route change requires explicit code. Without it, every URL on the site shares the homepage’s title and description. A crawler that fetches before render sees fifty pages with one title, which is a duplication signal as well as a lost opportunity.

Three, router links that are not links. As above, click handlers on non anchor elements. The fix is trivial for a developer and transformative for crawlability.

Four, hash based routing. URLs of the form /#/products/item are one URL as far as search engines are concerned, because everything after the hash is a fragment identifier rather than a separate address. Any site still using hash routing effectively has a one page website.

Five, blocked script resources. A robots.txt file that disallows a /static/ or /assets/ directory prevents Google from downloading the very JavaScript it needs to render the page. It then renders whatever it can, which is usually the empty shell. We find this on roughly one in ten framework builds, and it is almost always a leftover from an old template.

Where these failures compound is on sites whose commercial value lives in deep, templated pages rather than the homepage. Listing driven businesses are the clearest case, and our real estate SEO engagements routinely begin by establishing whether individual listing pages exist in the raw HTML at all. In our experience, the answer on a recently rebuilt site is no more often than yes, and nobody involved in the rebuild is aware of it, because every one of those pages renders perfectly in a browser.

Booking and enquiry driven businesses suffer most from these, because the pages at risk are usually the deep, specific, high intent ones. A hotel site where room type pages are generated client side will rank for the brand and nothing else, which is a pattern our hotel SEO work runs into repeatedly.

The recovery path is consistent enough to be predictable. Get the deep pages into the initial HTML response and existing authority does most of the remaining work. In our boutique hotel results engagement, dedicated boutique and heritage hotel pages displaced aggregator content by month 5.

Rendering Strategies Compared

There are four viable approaches and they are not equally suitable for every business. The table below reflects how we advise Singapore clients when a build decision is still open.

For most Singapore SME marketing sites, static generation is the correct answer and it is cheaper to host than the alternatives. For catalogue driven stores where stock and pricing change during the day, server side rendering or incremental regeneration is the honest choice. Client side rendering belongs behind a login, not in front of your customers.

Here is the contrarian part. Conventional wisdom in this space is to reach for dynamic rendering, which means detecting a crawler and serving it a pre rendered version while humans get the JavaScript app. It was officially described as a workaround years ago and has since been deprecated as a recommendation, yet it is still sold to Singapore businesses as a fix. It creates two versions of every page to maintain, it drifts out of sync, and it puts you one misconfiguration away from serving search engines something different from what users see. If your only reason for choosing it is that rebuilding sounds expensive, price the rebuild properly before deciding. For larger catalogue sites, our e-commerce SEO engagements have found the maintenance cost of a dynamic rendering layer frequently exceeds the one time cost of moving to server rendering.

How to Test What Google Actually Sees

Four tests, in ascending order of effort. Do them in order and stop when you find the problem.

Test one, view source. Right click your page and choose View Page Source. This shows raw HTML before any JavaScript runs. Use your browser’s find function to search for a distinctive sentence from your main content. If it is not there, your content is client side rendered. Also check whether your page title in the source matches the page you are on.

Test two, disable JavaScript. In your browser’s developer tools settings there is an option to disable JavaScript. Reload the page. What remains is approximately the worst case of what a crawler sees on first pass. If the page is blank, you now know the scale of your exposure.

Test three, the URL Inspection tool in Google Search Console. Enter a live URL, request a live test, and view the rendered HTML and the screenshot. This is the closest thing to an authoritative answer, because it is Google’s own renderer. Read the page resources list too, since blocked scripts are flagged there.

Test four, compare crawl output with and without rendering. Any professional crawler can be configured to crawl raw HTML or to execute JavaScript. Run both and compare the number of URLs discovered. If the JavaScript enabled crawl finds three hundred URLs and the raw crawl finds twelve, your internal linking depends entirely on scripts, and that is a structural problem rather than a tuning issue.

We recommend running test one on five representative pages every time your development team ships a significant release. It takes ten minutes and catches regressions that would otherwise take a quarter to notice.

What to Tell Your Developer

Most developers are not being careless. They are optimising for the things they were asked to optimise for, which are usually speed, interactivity and maintainability, and none of those conflict with search visibility if the requirement is stated up front. Here is the brief, in language that transfers cleanly.

Ask that every indexable page returns its main content, its <title>, its meta description and its canonical tag in the initial HTML response, before any client side JavaScript executes. Ask that all internal navigation uses real anchor elements with href attributes pointing at real URLs. Ask that routing is path based rather than hash based. Ask that no script or stylesheet required for rendering is disallowed in robots.txt. Ask that pages return correct HTTP status codes, because a JavaScript framework will happily serve a “not found” message with a 200 OK status, which tells search engines the page is fine.

That last point deserves emphasis. Soft 404s are endemic in framework builds. The visitor sees an error message, the crawler sees a successful response with thin content, and the URL stays in the index as a low quality page. Ask specifically for a genuine 404 status on missing routes.

We have seen pre rendered versions quietly serve stale copies of pages, pricing tables included, long after the live site was updated, with nobody noticing. Catalogue depth raises the stakes for wholesale sites like the one behind our B2B e-commerce results, where 14 category pages carry full specifications, MOQs and lead times, so any divergence between the two versions would be expensive.

The wider lesson is that crawlability problems are fixed in the technical layer, not with more content. In our ecommerce case study, a WooCommerce store had only 34% of its product pages indexed. The issue was not rendering, but the principle is the same: Phase 1 repaired robots.txt, the sitemap and redirect chains, and product indexation moved from 34% to 79% by the end of Month 2, before the category content work had even begun.

Field notes: In framework builds we often see navigation that is not made of crawlable links, page titles that never change between routes, and robots rules that block the very scripts Google needs to render the page. JavaScript also costs speed. In our law firm case study, a 4-solicitor general practice in Tanjong Pagar, the Month 1 technical audit lifted mobile Lighthouse from 52 to 81 through image compression, render-blocking JS deferral and font loading optimisation, and resolved 34 crawl errors, before any content or link investment. That is the order we recommend for any JavaScript-heavy site: make the pages fast and readable to Google first, because a slow, error-ridden site signals poor quality regardless of how strong the content is.

Our Take

The framing that helps most here is that JavaScript does not hide your content from Google, it delays it and adds failure points. Every dependency on client side execution is a bet that the render queue will run promptly, that the scripts will be reachable, that nothing will time out, and that the output will contain real links and real metadata. On a small site with strong authority you will usually win that bet. On a large, new or competitive site you will not win it consistently, and the losses are invisible in your own browser. Get the main content, the title, the description and the canonical into the initial HTML response, make every link a real link, use path based routing, and return honest status codes. Do those five things and the framework you chose stops mattering. If you are mid build and want the search requirements written into the specification before code ships, that is precisely the kind of question our team is asked most often, and a short conversation at that stage saves a great deal of money later.

Our team asks for server-side rendering or pre-rendering on anything commercially important well before launch, because retrofitting it after a JavaScript-heavy rebuild has already shipped is a far larger project than doing it up front.

Frequently Asked Questions

Can Google index a React or Vue site at all?

Yes. Google renders JavaScript using a current Chromium engine and can index content produced by React, Vue, Angular and similar frameworks. The difficulty is not capability but timing and reliability. Rendering happens in a separate, later pass, so content that exists only after scripts run is discovered more slowly and is vulnerable to timeouts, blocked resources and missing links. Server rendered output removes that dependency entirely.

What is hydration and why does it matter for SEO?

Hydration is the step where a server rendered HTML page is taken over by JavaScript so it becomes interactive. For search, hydration itself is not the issue, because the content was already present in the HTML. It matters for user experience, since a heavily hydrating page can feel unresponsive to taps for a moment after it appears, and that responsiveness is measured by Core Web Vitals, which do influence rankings indirectly.

Is server side rendering always better than client side rendering?

For pages you want found in search, yes, almost always. For pages behind a login, such as dashboards, account areas or internal tools, client side rendering is perfectly appropriate and often the better engineering choice. The decision should be made per section of the site rather than globally, and most modern frameworks support mixing both in one codebase.

Will switching to server side rendering cost a lot?

It depends heavily on how the application was written. If the codebase already uses a framework that supports server rendering as a configuration option, the change can be days rather than months. If the application relies on browser only APIs throughout, the refactor is larger. Get two quotes in SGD and ask each developer to estimate separately for the marketing pages and the application, because the marketing pages are usually where the search value sits and they are usually the easier half.

Why do all my pages show the same title in search results?

Because the router is changing the visible page without updating the document head. In a single page application this has to be done explicitly, usually through a head management library. Until it is, every route inherits whatever title was in the original HTML document, which is normally the homepage. It is a small code change with a disproportionate effect on click through rate.

Does Google scroll to load infinite scroll content?

No. Crawlers do not scroll, click or interact. Content loaded only on scroll will not be discovered through that mechanism. The standard solution is to provide genuine paginated URLs alongside the infinite scroll experience, so that users get the smooth interface while crawlers get real, linkable addresses for each page of results.

What is a soft 404 and why do frameworks cause them?

A soft 404 is a page that displays an error message to the user while returning a successful HTTP 200 status to the crawler. Frameworks cause it because routing is handled in the browser, so the server has already responded successfully before the application works out that the route does not exist. The result is non existent URLs sitting in the index as thin pages. Ask your developer to return a real 404 status.

Should I use dynamic rendering to serve crawlers a pre rendered page?

It is no longer recommended and should be treated as a last resort for legacy systems that cannot be changed. It doubles your maintenance burden, drifts out of sync over time, and carries a risk of serving search engines materially different content from users. If the underlying application can be moved to server or static rendering within a reasonable budget, that is the durable answer.

How do I know if my JavaScript is blocked in robots.txt?

Use the URL Inspection tool in Google Search Console, run a live test, and open the page resources list. Any file Google could not fetch is listed there with a reason. The common culprit is a broad disallow rule on a folder such as /assets/ or /static/ inherited from an old template. Removing that one line frequently resolves a rendering problem outright.

Do single page applications need a sitemap more than normal sites?

They benefit more from one, yes. When internal discovery depends on rendered links, a sitemap gives search engines a direct list of URLs that does not rely on rendering at all. It is not a substitute for crawlable internal links, because links also carry relevance and importance signals, but it provides a safety net for discovery while the deeper structural issues are fixed.