Technical SEO on WordPress: my pre-launch checklist

Is the site even allowed to be indexed?

I always start with the most basic check of all. Under Settings → Reading there’s a box labelled “Discourage search engines from indexing this site”. You tick it during development so Google doesn’t wander into a building site, and then you forget to untick it on launch day. It’s the most expensive oversight I know of, and the quickest to fix. Three seconds.

While I’m there, I look at the instructions given to crawlers (the well-known robots.txt). A site that has changed hosts sometimes carries a directive inherited from the old installation, or a crawl delay that slows Google down for no reason. I clean it up and make sure one line points to the sitemap.

The sitemap was listing templates and forms

The sitemap is the list of pages you offer Google to crawl. Plugins often slip their own technical content into it: templates, forms, mega menus. When I opened this site’s sitemap, it was doing exactly that, exposing page-builder templates and forms of no interest whatsoever to a search engine. In Rank Math, I excluded them from the sitemap and set them to noindex, which amounts to telling Google “don’t keep this in your index”.

A title that says something, and a single H1

A title like “Home – Site name” tells the person seeing it in search results nothing at all. For every page, I write a title of around 60 characters containing the target phrase, and a description of around 155 characters that makes someone want to click. It’s a writing job more than a technical one, and it’s usually the one left until last, wrongly.

The page’s main heading, the one known as the H1, deserves the same care. Animated headings in page builders are sometimes chopped into several pieces for visual effect. The result is that the search engine only reads a fragment, like “Création” instead of “Création de site web”. That’s precisely what I found on this site during the audit. I now check in the page source that every page has one H1, readable from start to finish.

Images that are described and light

Google can’t see an image. It reads what’s written next to it. In the Image block, I fill in alt text for every picture that carries meaning, and leave the field empty for purely decorative ones, so as not to clutter things for people using a screen reader. I also check weight and dimensions, and make sure lazy loading is on so that images further down the page don’t weigh on the first impression.

When an address changes, it has to redirect

A rebuild almost always changes some page addresses. Every old address still sitting in Google or in an external link has to send people to the new one, permanently (a 301 redirect). On this site, the old /blog/ page now redirects to /projets/, so that neither the visitors arriving via the old link nor the rankings built up over time are lost.

In the same spirit, I switch off the archives that serve no purpose. On a single-author site, the author archive duplicates content and reveals the login name into the bargain. Date archives go the same way if they add nothing for the reader.

From 58 stylesheets down to 7

Number of requests, page weight, Core Web Vitals (the speed indicators Google takes into account): I measure before, then after. Without measuring, you’re left with impressions. On this site, every page was loading 58 stylesheets before the rebuild. Moving from Elementor to WordPress’s native blocks brought that down to 7. I hadn’t expected such a sharp gap, and it turned out to be the number that convinced me the switch was worth it.

Measuring from day one

The sharing tags (Open Graph, the ones that give you a proper preview card when you paste a link on LinkedIn), structured data, Search Console and analytics all need to be working from launch. Here, Site Kit connects Search Console and analytics in a few clicks from the dashboard. The consent banner has to be in place at the same time, GDPR-compliant, otherwise you’re measuring without the right to. A site that goes live without measurement is a month of data lost that you’ll never get back.

After launch: what Search Console tells you

Launch day is not the finish line. In the weeks that follow, the Pages report in Search Console shows which addresses Google has indexed and, more usefully, why others are left out. “Discovered, currently not indexed” on a young site usually means Google knows the page exists but hasn’t got round to it yet. “Alternate page with proper canonical tag” is normal on a bilingual site or on addresses with parameters. A 404 listed there is worth tracing back to the link that still points to it.

I learned to check this early. On a home automation media site I work on, two weeks after the relaunch the homepage was indexed but the articles were still unknown to Google: no sitemap had been submitted in Search Console. Submitting it and requesting indexing for the key articles is the first thing I now do once a site is live.

Canonical tags and structured data

Two things most people never look at. The canonical tag tells Google which address is the reference when the same content can be reached in several ways: with or without a trailing slash, with tracking parameters, through a category. SEO plugins set it automatically, but I check it on a few templates, because page builders and multilingual setups sometimes get it wrong.

For structured data, I run a few pages through Google’s Rich Results Test: an article should declare Article, a product page Product, the breadcrumb BreadcrumbList. A small error there won’t sink a page, but clean markup is one more sign of a site that is properly looked after.

Questions I often get about technical SEO on WordPress

Is Rank Math or Yoast enough for technical SEO?

They cover titles, descriptions, the sitemap, canonical tags and basic structured data. They won’t fix a slow theme, a page loading dozens of stylesheets, a missing redirect or a heading split into pieces. The plugin is a tool; the checklist is still yours to run.

How long does Google take to index a new WordPress site?

Anywhere from a few days to several weeks. Submitting the sitemap in Search Console and requesting indexing for the most important pages speeds things up, and a few links from other sites help more than anything else.

How often should a technical audit be done?

Before every launch, after any redesign or major plugin change, and otherwise once a quarter. That is the rhythm I follow on the sites I look after.

A check worth repeating every quarter

This checklist isn’t just for launch day. Every new plugin and every partial redesign can bring back a problem you thought was sorted. A quick audit each quarter is enough to keep a site healthy. So I don’t miss anything, I run through the ten points in this order.

• Indexing is allowed under Settings → Reading.
• The sitemap only contains useful pages.
• The crawler instructions are clean and point to the sitemap.
• Every page has its own title and meta description.
• One H1 per page, complete and readable.
• Images are described and lightweight.
• Old addresses redirect to the new ones.
• Useless archives are switched off.
• Performance is measured before and after.
• Sharing tags, structured data, Search Console, analytics and consent are in place.