How to Get a New Website Indexed by Google: A Checklist That Actually Works

Before you submit anything, check nothing is blocking you

Every hour I have spent helping someone with an indexing problem, roughly half the cases ended here. The site was fine, the content was fine, and one line of configuration was telling Google to stay away.

Check these four things first, in this order:

1. 1robots.txt. Open yoursite.com/robots.txt in a browser. Look for Disallow: / on its own, which blocks the whole site. Staging sites ship with this and it survives the move to production more often than anyone admits.
2. 2The noindex meta tag. View source on a page that will not index and search for noindex. WordPress has a Discourage search engines checkbox in Settings, Reading, and it writes this tag on every page.
3. 3Canonical tags. If page A carries a canonical tag pointing at page B, you have told Google not to index page A. Check that each page's canonical points at itself unless you meant otherwise.
4. 4HTTP status. The page must return 200. A soft 404, a redirect chain, or a 401 behind a password will all stop indexing cold.

Step 1: Verify the domain in Google Search Console

This is not optional and it is not just for reporting. Verification is what gives you URL Inspection, sitemap submission, the index coverage report, and access to the Indexing API for your own pages. Without it you are working blind.

Choose a domain property rather than a URL prefix property when you set it up. A domain property covers http and https, www and non-www, and every subdomain in one go. A URL prefix property covers exactly one of those, which is how people end up with data split across four properties and a confusing picture in all of them.

Domain properties verify through a DNS TXT record at your registrar. It usually takes a few minutes to propagate, sometimes a few hours.

Step 2: Submit an XML sitemap, and keep its dates honest

A sitemap is a list of the URLs you want Google to know about, with a lastmod date for each one. Submit it under Sitemaps in Search Console.

The part people get wrong is lastmod. It is meant to say when the page's content actually changed. Two failure modes, both common:

• Frozen dates. The sitemap is generated once at build time and then never changes. Ours did this for weeks. Google re-fetches a file that never changes less and less often, which quietly removes the channel you were relying on.
• Fake fresh dates. Every URL gets today's date on every request. Google works out quickly that the dates mean nothing and stops using them as a signal.

Set lastmod from the page's real modification time. If your platform cannot do that, leaving lastmod out entirely is better than making it up.

Step 3: Link every new page from a page Google already crawls

This is the step that gets skipped, and the one that produced the clearest result for us.

We had a page reachable only from the sitemap. Nothing on the site linked to it. Search Console reported it as discovered, currently not indexed, and never crawled. Google knew the URL existed, from the sitemap, and decided it was not worth fetching.

A page whose only route in is the sitemap is an orphan, and Google treats orphans as low priority regardless of what the sitemap says. Adding a link to it from our indexed homepage put it on a path Googlebot was already walking.

So for each new page, ask which already-indexed page should link to it. The homepage, a category page, a recent post, a navigation menu. Use descriptive anchor text that says what the page is about, since that text is one of the few ways Google understands the destination before fetching it.

Step 4: Request indexing for the pages that matter

In Search Console, paste a URL into the inspection bar at the top, wait for the result, then click Request Indexing.

This is rate limited to roughly a dozen or so URLs a day and it cannot be automated, which is precisely why it still carries weight. It is a manual signal from a verified owner. Use it on pages that genuinely matter: a new product page, a piece you want picked up quickly, a page you just fixed.

For automated pushes at volume, the Indexing API is the equivalent, and it also requires owner permission on the property. Worth knowing what it does and does not promise, which we covered in our field notes on pushing pages to Google.

Step 5: Give Google a reason to come back

Steps 1 to 4 are mechanics. This one is the actual constraint, and no tool shortcuts it.

How often Google crawls your domain is a judgement about whether the visits are worth making. On a brand new domain with no links, that judgement starts low. Our indexed homepage went five days between crawls. Nothing you submit changes that number. What changes it is a history of pages worth keeping and other sites pointing at you.

• Publish pages that answer something specific. A page that is the best answer to a real question gets linked to. A thin page does not, no matter how it is submitted.
• Get a handful of genuine links. A mention from one relevant site does more for crawl rate than any volume of pings. This is slow and there is no version of it that is fast and safe.
• Update existing pages and let lastmod reflect it. A site where things change is one worth revisiting.
• Fix slow pages and rendering problems. If your content only appears after JavaScript runs, check the rendered HTML in URL Inspection to confirm Google sees it.

Common mistakes

How long this realistically takes

I will not give you a number, because the honest answer depends on one thing and it is not your submission method.

On an established domain that Google crawls daily, a new page linked from the homepage often appears within hours. On a domain registered last month with no inbound links, the same page can sit for weeks with everything configured perfectly. Same checklist, very different outcome, because crawl demand is different.

If someone promises you a fixed time for any URL, they are describing something other than how crawling works. We went through how those claims are produced.

Frequently asked questions