Short answer: A site that is live but absent from Google is almost never being penalised. It is usually either not crawled, crawled but judged not worth indexing, or rendered entirely in JavaScript so Googlebot sees an empty page. Google Search Console tells you which of the three it is, and each has a different fix.
Key Takeaways
- Check the Search Console Page Indexing report before changing anything. The status string names your problem.
- "Discovered, currently not indexed" is a quality and crawl-budget signal, not a bug.
- Client-side rendered sites wait in a second queue, and that queue is where most new sites stall.
- Prerendering or server-side rendering removes the entire class of problem rather than working around it.
- A new site taking two to four weeks to index is normal. Three months is not.
First, Find Out Which Problem You Have
Open Google Search Console, select your property, and go to Indexing, then Pages. Below the summary chart there is a table titled "Why pages are not indexed". That table is the whole diagnosis. People skip it and start rewriting content, which fixes nothing if the real problem is a blocked crawler.
The statuses you will usually see fall into three groups, and they mean very different things.
What Each Status Actually Means
The wording is terse and easy to misread. Here is the plain version of the four you are most likely to hit.
| Status | What it means | What to do |
|---|---|---|
| Discovered, currently not indexed | Google knows the URL exists but has not crawled it. Usually a crawl budget or perceived quality decision. | Improve internal linking to the page, strengthen the content, speed up the server. |
| Crawled, currently not indexed | Google fetched the page and decided not to index it. This is a quality judgement. | The page needs to be more useful or more distinct than what already ranks. |
| Blocked by robots.txt | You told Google not to crawl it. | Fix the robots.txt rule. This one is self-inflicted and quick. |
| Page with redirect / Alternate page with canonical | Google indexed a different URL instead. | Check your canonical tags point where you think they do. |
Two of those four are content problems and two are technical problems. Treating a quality judgement as a technical bug is the most common wasted month in SEO.
If Your Site Is Built in JavaScript, Start Here
Google does not index a JavaScript page in one pass. It crawls the HTML first, and if the meaningful content is not in that HTML, the page goes into a separate rendering queue to have its JavaScript executed later. That second pass can happen quickly. It can also sit for days.
This is the part that catches teams out. Your Vue, React, or Angular site looks complete in a browser because your browser runs the JavaScript. Googlebot's first look sees whatever the server actually sent, which for a standard single-page app is an empty <div id="app"></div> and a script tag.
You can check this in about ten seconds. Do not use "View Source" in a modern browser, because it can mislead. Use curl:
curl -s https://yoursite.com/ | grep -c "<h1"If that returns 0, Googlebot's first pass sees no heading either. Google's own JavaScript SEO documentation covers the rendering behaviour in detail.
The Fix That Removes the Problem Instead of Managing It
You can try to work within the rendering queue by trimming bundles and speeding up hydration. It helps a little. The better answer is to stop depending on the queue at all, by sending real HTML from the server.
There are three practical routes, in rising order of effort:
- Static prerendering at build time. Every route is rendered to a real HTML file during the build. Best for marketing sites, service pages, and blogs where content changes on deploy rather than per request.
- Server-side rendering. HTML is generated per request. Needed when pages are personalised or data changes constantly.
- Dynamic rendering. Serving prerendered HTML to bots only. It works, but it is a workaround, and it means maintaining two paths forever.
For most business sites, the first option is enough and costs the least to maintain.
A Worked Example: This Site
This site is a Vue single-page application, which is exactly the setup described above. Rather than hope the render queue kept up, we build it with static prerendering: every route, including all of our service pages and every blog post, is written to a real HTML file at build time.
The result is that the page you are reading was delivered as complete HTML. Its heading, body text, and structured data were all in the first response, before any JavaScript ran. You can verify that yourself with the curl command above against this page. There is no rendering queue to wait in, because there is nothing left to render.
The same build also writes a plain-text copy of every page, and submits new URLs to Bing automatically. Indexing is the floor that everything else stands on, so it is worth removing the uncertainty rather than monitoring it.
How Long This Should Take
A brand new domain with few links usually takes two to four weeks to index properly, and that is normal rather than a problem to solve. What is not normal is a site that has been live for three months with most pages still showing "Discovered, currently not indexed". At that point something structural is wrong, and more content will not fix it.
When the cause is rendering, indexing often improves within one or two crawl cycles of the fix shipping, because the obstacle was mechanical. When the cause is a quality judgement, expect to be working on it for months, because you are being asked to earn the slot.
What This Costs to Fix
If the cause is rendering, this is development work rather than marketing work, and it is usually measured in days. We build business websites from $500 and web applications from $1,500, with full timelines and scope on our pricing overview. An indexing diagnosis on an existing site is normally a short, fixed-scope piece of work, and final cost depends on the size of the site and how it is built.
If you want the diagnosis done properly before committing to anything, our SEO service page explains how we audit and fix this in the codebase rather than handing over a PDF of recommendations.
Frequently Asked Questions
Frequently Asked Questions
How long should a new website take to appear on Google?
Two to four weeks is typical for a new domain with few inbound links. Submitting your sitemap in Search Console and requesting indexing on your most important pages speeds up discovery. If most pages are still unindexed after three months, the cause is structural rather than a matter of waiting longer.
Does "Discovered, currently not indexed" mean my site is penalised?
No. It means Google knows the URL exists but has not spent crawl budget on it yet, usually because it does not expect the page to be worth indexing. It is a prioritisation decision, not a penalty. Stronger internal linking to the page and more substantial content are the usual fixes.
Can Google index a React or Vue site at all?
Yes, but through a second rendering pass that can lag behind the initial crawl. The content is not invisible, it is delayed, and on large sites some of it never gets prioritised. Prerendering or server-side rendering removes the dependency entirely by putting real HTML in the first response.
Will submitting my sitemap force Google to index my pages?
No. A sitemap helps Google discover URLs, but it does not oblige Google to index them. Discovery and indexing are separate decisions. If pages are being discovered and then not indexed, adding them to the sitemap again changes nothing, because discovery was never the bottleneck.
Should I use dynamic rendering to serve HTML only to bots?
It works, and it is a reasonable short-term fix on a large legacy application. The drawback is that you maintain two rendering paths indefinitely, and they drift apart over time. If prerendering or server-side rendering is achievable, it is the more durable choice.