How to Index a WordPress Site (Step by Step)

WordPress powers a large share of the web, which means Google is very good at crawling it. If you want to know how to index a WordPress site, the honest answer is that most of the work is removing obstacles, not adding tricks. WordPress ships with sensible defaults, then one checkbox, one plugin setting, or one theme quirk quietly undoes them. This guide walks through the steps in the order a new site actually needs them: confirm nothing is blocking Google, give Google a map, submit the URLs that matter, and then verify what happened rather than assuming.

One framing before the steps. Submission and indexing are different events. You can do everything below correctly and still wait, because Google decides what enters its index on its own schedule and for its own reasons. The steps improve your odds and shorten the wait. They do not oblige Google to do anything.

Step 1: uncheck the box that blocks everything

Go to Settings, then Reading, and look at “Discourage search engines from indexing this site”. If it is ticked, WordPress adds a noindex signal to every page, and Google honours it. Google’s own documentation is blunt about this: a page carrying noindex is dropped from results regardless of how good it is or who links to it.

This checkbox is the single most common reason a WordPress site sits unindexed for months. Developers tick it on the staging site, then migrate to production with the setting intact. Check it first, even if you are sure. It takes ten seconds.

Step 2: check robots.txt and your SEO plugin

WordPress generates a virtual robots.txt, and SEO plugins (Yoast, Rank Math, All in One SEO) can rewrite it. Visit yourdomain.com/robots.txt and read what is actually being served, not what you remember configuring. A stray Disallow rule on / or on a directory your content lives under will stop crawling outright, and it is a surprisingly common leftover from staging setups.

While you are in the SEO plugin, check its per-post and per-type settings. Most plugins can set entire content types (posts, pages, categories, tags) to noindex. That is often sensible for tag archives. It is fatal when someone has applied it to posts.

Step 3: give Google a sitemap

WordPress generates a basic sitemap at /wp-sitemap.xml out of the box, and most SEO plugins replace it with their own, usually at /sitemap_index.xml. Either is fine. What matters is that the sitemap exists, lists your real URLs, and stays current, which Google describes in its guidance on building and submitting a sitemap.

Open the sitemap in a browser and spot-check it. Sitemaps that list draft URLs, dead URLs, or the wrong domain (http instead of https, www when the site canonicalises to bare) are worse than no sitemap, because they teach Google to distrust the file.

If you use Search Console, submit the sitemap there. If you do not, reference it from robots.txt with a Sitemap: line. Both routes work; Search Console simply gives you a receipt.

Step 4: how to index a WordPress site’s individual URLs

A sitemap announces your URLs. It does not queue them for crawling with any urgency. For the pages you care about now, ask directly.

The manual route is Search Console’s URL Inspection tool, which lets you request indexing for a URL one at a time. It works, and for a five-page site it is all you need. It does not scale: each URL is inspected and submitted by hand, and the tool imposes daily limits.

For anything larger, a launch, a migration, a site with a publishing cadence, batch submission makes more sense. This is where a tool like AIndexify fits: paste the URLs or upload a CSV, and each one is submitted to the indexing pipeline without Search Console access, ownership verification, or a tag on the site. Usefully for WordPress, it runs a preflight check first. If a URL still carries noindex from step 1, or robots.txt from step 2 blocks it, or the page 404s, it reports “Couldn’t check” and refunds the credit instead of billing a submission that cannot succeed.

Step 5: fix the WordPress-specific traps

If the basics are in place and pages still are not being picked up, the cause is usually one of a familiar set: duplicate archive pages competing with posts, canonical tags pointing somewhere unexpected, thin auto-generated pages diluting the site, or a theme that renders content only after JavaScript runs. We keep a full diagnostic list in WordPress Not Indexed: The 10 Most Common Causes, which is the companion piece to this guide and takes each cause in turn.

The short version: every archive, tag, and pagination URL WordPress creates is a page Google may crawl instead of your content. Keeping the sitemap limited to URLs you actually want indexed does more than most plugins’ advanced settings.

Step 6: verify, do not assume

Submission is a request. Indexing is Google’s decision, and the two are separated by hours, days, or sometimes an indefinite silence. A green tick that says “submitted” tells you the request was delivered, nothing more; the difference is worth understanding because submitted is not indexed, and the gap between the two is where most WordPress owners lose track.

So close the loop. Check each important URL against live Google results after a day, again after two, again after a week. If a page is indexed, note the date. If it is still absent after a week, go back to step 5 with a specific URL in hand rather than a vague sense that “the site isn’t indexing”.

That checking schedule is tedious to run by hand. Whatever you use to automate it, insist on two properties: it should check against live Google results rather than trusting a delivery receipt, and it should attach a date to every answer, indexed on this day or not indexed as of this day. Either answer is useful. Only the vague middle is not.

A WordPress site with the blocks removed, a clean sitemap, and deliberate submission is as well-positioned as a site can be. The rest is Google’s call. See where your pages actually stand: submit your URLs and get a dated answer for each one.