How to Get a New Website Indexed by Google: The Launch-Day Checklist for a Domain With No Links Yet

Every guide on this subject ends at the same place: make a sitemap, open Search Console, click Request Indexing. That advice is correct. It is also about fifteen percent of the job, and it quietly assumes something that is not true for a site you launched this morning, which is that Google already has a reason to come back.

I found this out the hard way when I put ten brand-new domains live in the same week. Same codebase, same deploy pipeline, ten different businesses. I did the sitemap step and the request-indexing step on all ten, felt organised about it, and then watched several of them sit there doing nothing for weeks while a couple got picked up almost immediately. The difference had nothing to do with the steps I had followed. It had to do with whether anything on the open web pointed at the domain at all.

So this is the version of the indexing guide I wish I had read. It covers what to do on day one, what most write-ups get wrong about crawl budget, what the Search Console coverage states actually mean, and what to do in week three when a site is still not in the index.

Why a brand-new domain does not get indexed just because you submitted it

Google decides how much attention to give a site using what it calls crawl demand, and its own documentation is unusually direct about the inputs. There are three: perceived inventory, which is how many URLs Google knows exist on the site; popularity, which is how much the URLs are linked to or visited from elsewhere; and staleness, which is how often the content changes. You can read the full explanation in Google's guide to managing crawl budget for large sites.

Now look at a domain that went live an hour ago. Perceived inventory is whatever your sitemap claims. Popularity is zero, because nothing on the internet links to it. Staleness is unknown, because there is no history to compare against. Two of the three signals Google uses to decide whether to spend crawling on you are missing entirely, and the third one is a file you wrote yourself.

That is the actual problem. Not your sitemap format. Not a missing meta tag. The site has no reason to be crawled yet, and clicking Request Indexing harder does not create one.

The five things I do the day a new domain goes live

This is the exact sequence, in order, and the order matters because steps four and five are the ones that do the work.

Verify in Search Console at the domain level

Add the property as a Domain property with a DNS record, not as a URL-prefix property. A URL-prefix property only covers one exact protocol and subdomain combination, so if you verify the www version and your site resolves to the bare version, you will be staring at an empty dashboard wondering why nothing is happening. The DNS record covers every variant at once. When you are setting up ten of these, it is also the difference between one process and forty.

Ship a sitemap and reference it from the robots file

Submit the sitemap inside Search Console, and add a sitemap line to the robots file so any crawler that finds the site independently can find the URL list too.

One thing worth updating if you learned this years ago: the old trick of pinging Google with a sitemap URL to nudge a recrawl no longer does anything. Google retired the sitemaps ping endpoint in 2023 and the replacement is nothing more exciting than submitting through Search Console and keeping accurate lastmod values in the file. Accurate is the operative word. If your generator stamps every URL with today's date on every build, the lastmod values carry no information and get ignored.

Request indexing on two URLs, not twenty

Use the URL Inspection tool on the homepage and on the single best page you have. That is it. Google's own documentation on asking for a recrawl says two things people skip past: there is a quota on submitting individual URLs, and requesting the same URL repeatedly will not get it crawled any faster. It also puts the honest timeline in plain language, which is anywhere from a few days to a few weeks.

Treat the quota as a scarce resource for the pages you genuinely care about. Spending it on a whole sitemap's worth of thin pages on launch day is the most common way I see people waste the one manual lever they have.

Link the new domain from something Google already crawls

This is the step that separated the fast sites from the slow ones, and it is the step nobody writes down. Discovery through links is still the primary way Google finds a site. If you own anything that already gets crawled regularly, a blog, a main product site, a personal site, put one honest, relevant, followed link on it pointing at the new domain. Not a footer link block across all ten sites pointing at each other, which is a pattern that helps nobody and looks exactly like what it is. One contextual link from a page that already earns crawls.

If you own nothing that gets crawled, the substitutes are the ordinary ones: a real profile somewhere, a submission to a directory a human would actually use, a post on a platform that gets indexed. The goal is not link equity at this stage. The goal is a crawler finding a path to the domain that does not depend on your sitemap being believed.

Make the first ten pages worth keeping

Google can crawl a page and still decline to index it. That is not a bug or a penalty, it is a judgement, and on a new domain with no track record the judgement is harsher because there is nothing else to go on. Ten pages that answer a real question beat sixty pages of generated filler, and the filler actively hurts, because it teaches Google that crawling your site returns low value and there is no reason to hurry back.

I run the writing side of this across several properties with an agent workflow rather than by hand, which is a topic in itself. What matters here is the standard, not the tooling: nothing goes live that I would be embarrassed to send to a person.

What most guides get wrong about crawl budget on a small site

You will see crawl budget invoked constantly in indexing advice aimed at small sites. It is almost always the wrong diagnosis.

Google states the thresholds directly in that same crawl budget guide. The sites that need to think about it are large sites with over a million unique pages whose content changes at least weekly, or medium and larger sites with more than ten thousand unique pages whose content changes daily. Google adds that these are rough estimates for classification rather than exact cutoffs. Either way, a forty-page site launched last Tuesday is not in the conversation.

Your new site is not being throttled. It is not being rationed. It is being ignored, which is a completely different problem with a completely different fix. Throttling is solved by reducing waste. Being ignored is solved by giving Google a reason to come, which is steps four and five above.

The one place that page does apply to a small site is the third category it lists, which is sites with a lot of URLs sitting in the Discovered but not currently indexed state. That state is worth understanding properly.

How to read what Search Console tells you in week two

Two coverage states get confused constantly, and they mean opposite things about what you should do next.

Discovered, currently not indexed means Google knows the URL exists and has chosen not to crawl it yet. This is the normal state for a new domain with no external signals. Nothing is broken. Google has weighed the cost of crawling against the evidence that it is worth it, and the evidence is thin. More requests will not change that. A link from a crawled page will.

Crawled, currently not indexed means Google came, read the page, and decided not to put it in the index. This one is about the page, not about discovery. The usual causes are that the content is thin, that it duplicates something else, or that it is one of a set of near-identical pages where Google has picked a different URL as the canonical one. If you are running multiple sites off one codebase, near-identical pages are an easy trap to fall into, and I wrote about why duplicate content across multiple websites is not the penalty risk people think it is but is very much a wasted-crawl risk.

A third state, Excluded by noindex tag, is worth ruling out on any site built from a template. Staging configuration that ships to production is a real and unglamorous cause of nothing ever getting indexed, and it takes ten seconds to check.

What to do in week three if a site is still not indexed

At this point stop repeating day-one actions and start changing inputs.

Publish something new on the domain, so there is fresh material and a genuine lastmod change rather than a rebuild artifact. Add a second inbound link from a different crawled source. Look at whether the pages that are indexed are the ones you wanted, because sometimes the homepage is in and the money page is not, which is a canonical or an internal-linking problem rather than an indexing problem. Check that internal links actually exist between your pages, since an orphan page reachable only from the sitemap is a page Google has every excuse to skip.

And submit to the other engines while you are there. IndexNow is a free open protocol that lets you notify participating search engines the moment content is added, updated or removed, and Bing and its partners use it. It is not a Google solution and I would not present it as one, but Bing traffic is real traffic, it converts fine, and the setup is a one-time job. There is no reason to leave it on the table when you are launching several sites at once.

Beyond that, patience is a legitimate strategy. Google's own stated range runs to several weeks. Half the panic I see about indexing is someone three days into a normal timeline.

Where the manual work stops and the loop starts

Everything above is launch-day work. It does not scale to a portfolio, and it should not have to. Once the sites are in the index the job changes from getting crawled to deciding what to publish next, which is a weekly data question rather than a daily clicking one. I run that as a scheduled sweep across every property, which pulls fresh Search Console data, requests indexing for anything published since the last run, and keeps each sitemap current. The reasoning behind it is in my write-up on the Search Console loop that decides what I publish next.

The architecture that makes ten sites survivable in the first place is a separate matter again, and I covered it in how I manage multiple websites from one codebase. Indexing is much easier when adding a new property is a config change rather than a new project.

If you want to watch the whole thing get built rather than read about it, the full replay of the Domain Factory session is available instantly. It is the session where I take one repo, ten sites and ten separate Stripe businesses from an empty folder to live, and the launch checklist in this article is the part that runs right after the deploy.

The honest version of the timeline

Here is what I would tell someone launching their first site, having now done it many times.

Indexing is not the finish line. It is the point at which Google has agreed to consider you. A page that gets indexed on day four and then never ranks for anything is more common than a page that never gets indexed at all, and the second problem gets all the attention because it is the one that shows up in a dashboard. If your site is indexed and getting no traffic, indexing advice is no longer your bottleneck.

The sequence that actually works is unglamorous: give Google a path to the domain that is not your own sitemap, put something on the domain worth indexing, then leave it alone long enough to be judged. Everything else is decoration.

Get the systems, not just the checklist

The Reinventing AI Accelerator is where I hand over the working versions of this. Members get the live training sessions, the replays with instant access, and the vault of AI apps, tools and agents behind them, including the publishing and indexing routines I run across my own properties. If you are building more than one thing at a time and the manual version has started to hurt, that is who it is for. One link, no pressure, have a look and decide for yourself.

Frequently asked questions

How long does it take Google to index a new website?

Google's own guidance puts crawling anywhere from a few days to a few weeks, and indexing follows crawling rather than happening at the same moment. For a domain with no inbound links, the longer end of that range is normal rather than a warning sign. The variable that moves the timeline most is whether anything Google already crawls regularly points at your site.

Does requesting indexing multiple times make it faster?

No. Google's documentation states plainly that requesting a recrawl multiple times for the same URL will not get it crawled any faster, and there is a quota on submitting individual URLs. Save the requests for pages you genuinely want prioritised, and put the effort into discovery signals instead.

Why is my page showing as Discovered but not currently indexed?

Google knows the URL exists but has not chosen to crawl it yet. On a new site that almost always means there is not enough evidence the page is worth the crawl. A relevant link from a page that already gets crawled fixes this far more reliably than any Search Console button.

Do I still need to ping Google when I update my sitemap?

No. That endpoint was retired in 2023. Submit the sitemap once through Search Console, reference it from the robots file, and keep the lastmod values accurate and meaningful. If your build stamps every URL with the current date every time, those values are noise and will be treated as such.

Should I use IndexNow if I care mainly about Google?

It costs one afternoon and covers Bing and its partner engines, which is real traffic you would otherwise be slower to earn. Treat it as a supplement to the Google work rather than a replacement for it, and do it once when you set the site up so it is never a decision again.