Most WordPress launch problems are settings, not code. One checkbox left on from staging. Two plugins writing the same tag. A page builder that adds the text after the page has loaded.
None of these shows on the screen. The site looks finished, the client signs it off, and three weeks later someone asks why Google has not indexed it, or why the contact form has been silent.
This checklist is a launch gate. It has fourteen checks to run on the built site, not on the plan. Each one says why it matters, how to check it and what to do. Mark each Pass, Fail or Not sure, and the board builds the list of what to fix before the site goes live. It works as a sign-off sheet between a client and a developer.
Where the article says what WordPress does by default, it means the current release, WordPress 7.1.4, published on 28 October 2026, and it links to the WordPress page that says so.
Before a WordPress site goes live, run this WordPress SEO checklist: fourteen checks on the built site. Confirm the search visibility setting is off in production, each page has one title and one canonical, there is one sitemap and the intended robots.txt, the main text is in the HTML, speed holds with every script switched on, and forms deliver. Repeat four of the checks on the live address on launch day.
Eight Checks Need No Developer
You do not need to read code to run most of this. Eight checks need only a browser and a login to the WordPress dashboard. Six need a developer, or someone with access to the server. The board below lets you filter by either group.
Run the checks on the staging site once the build is complete, and repeat checks 1, 6, 7 and 13 on the live address on launch day. Those four change when the site moves.
Where each check sits, from staging to four weeks after launch
Four checks are repeated on launch day because they change when the site moves.
-
Check 2
While the site is on staging
Keep staging closed to crawlers and to the public.
-
Checks 4, 5, 8, 9, 10, 11
When the build is complete
Check what every page template outputs: canonical, title, text in the HTML, headings and structured data. Decide what happens to the pages WordPress creates on its own.
-
Checks 3, 12, 13, 14
The week before launch
Finish the redirect list, test speed with everything switched on, send test enquiries and set up backups.
-
Checks 1, 6, 7, 13
Launch day, on the live address
Confirm the site is open to search engines, the sitemap is the right one, robots.txt is the intended one and a test enquiry still arrives.
-
After launch
Weeks one to four
Watch the sitemap, the Performance report and the enquiry inbox.
0 of 0 checks run
Start with check 1. It takes two minutes and it is the one that stops a launch being seen at all.
Keep going. Mark "Not sure" where you could not tell; those are questions for your developer.
Nearly there. Anything marked Fail goes on the list to fix before launch.
All fourteen checks run. Fix anything marked Fail, in the order shown under "Fix these first", before the site goes live.
0 pass0 fail0 not sure
Fix these first
1. The search visibility setting is off in production and on in staging
WordPress has one checkbox that asks search engines to stay away from the whole site. It is useful on a staging site and harmful on a live one. It is also the setting most often carried over by accident when a staging site is copied to production.
The option is "Discourage search engines from indexing this site", on the Reading settings screen. Since version 5.3 it works by printing a robots meta tag with noindex, nofollow on every page. It does not add a block to robots.txt.
How to check
In the dashboard, open Settings, then Reading, and look at the checkbox. The Site Health screen, under Tools, also reports whether the site discourages search engines.
Then check what the page sends. Open any page, press Ctrl and U to view the source, and search for noindex.
What to do
- Staging: the box is ticked.
- Production: the box is clear, and no page you want found has
noindexin its source. - Repeat this on the live address on launch day. Do not rely on what staging showed.
2. Staging is closed to crawlers and people, and nothing links to it
A staging site that search engines can reach is a second copy of your website. It can be indexed beside the real one, with test content and half-written pages.
The setting in check 1 is a request, not a lock. Two points from Google's documentation explain why it should not be the only protection. A noindex rule works only if the page is not blocked in robots.txt, because Google has to fetch the page to see the rule. And robots.txt controls crawling, not indexing. A password on the staging site avoids both problems, because nothing can be fetched without it.
How to check
Open the staging address in a private browser window. You should be asked for a password before any page loads.
Then search the built site's source for the staging address. Menus, images, canonical tags and sitemap entries sometimes keep it after a copy.
What a failure looks like
- The staging site opens for anyone who has the address.
- Staging is protected only by a robots.txt block.
- Pages on the production build link to, or load images from, the staging address.
3. Permalinks are final, and every old URL has a redirect
The address of a page is the thing search engines and other websites remember. Change it after launch and you start again for that page, unless a redirect carries visitors and search engines across.
WordPress offers several permalink structures: Plain, Day and name, Month and name, Numeric, Post name and Custom. Choose one before content is loaded and do not change it afterwards.
If the new site replaces an old one, Google's guidance on site moves is specific. Map each old URL to its new one. Use permanent, server-side redirects. Avoid chains, where one redirect leads to another. Keep the redirects for at least a year.
How to check
Open Settings, then Permalinks, and confirm the structure is the one agreed.
Ask for the redirect list as a spreadsheet: old address, new address. Then request a few old addresses and read the first line of each response:
curl -sI https://www.example.com/old-page/
What a pass looks like
- Every old address with traffic or links is on the list.
- Each returns a 301 and a
Locationline with the final address, in one step. - Nothing redirects to the home page for want of a better match.
Our guide to a website redesign without losing SEO covers how to build the redirect map.
4. Each page outputs one canonical, pointing to itself
A canonical tag tells search engines which address is the main one for a page. Two tags that disagree, or one that points somewhere else, leave the choice to the search engine.
Google treats the canonical as a hint, not an instruction. It recommends a self-referencing canonical on each page, written as an absolute URL. WordPress core prints a canonical link on single posts and pages. A theme or a plugin may print another.
How to check
On five different kinds of page (home, a service page, a blog article, a category, a contact page), view the source and search for rel="canonical".
Or count the tags from a terminal:
curl -s https://www.example.com/your-page/ | grep -c 'rel="canonical"'
What a failure looks like
- The count is 2 or more.
- The address in the tag is the staging address, or uses
httpwhere the site useshttps. - A page points to a different page as its canonical without a reason anyone can give.
5. Titles and descriptions come from one source
On a WordPress site, the theme can write the title tag, and so can a plugin. When both do, a page ends up with two titles or two descriptions, and you no longer control which one a search engine reads.
Decide which part of the site owns these tags, and make sure nothing else writes them.
How to check
View the source of the same five pages and search for <title and name="description". There should be one of each.
Read them as a searcher would. Does each title say what that page is, in words a buyer uses?
What a failure looks like
- Two title tags or two descriptions on one page.
- The same title on many pages, or the site name alone.
- Titles left from the theme's demo content, such as "Home" or "Sample Page".
6. There is one XML sitemap, and it lists only pages meant to be indexed
A sitemap is the list of addresses you are asking search engines to consider. It should match the site you mean to publish: no test pages, no thank-you pages, nothing set to noindex.
WordPress has had XML sitemaps in core since version 5.5, at /wp-sitemap.xml, with up to 2,000 URLs per file. Core switches the sitemap off when the setting in check 1 is on. A plugin may produce a second sitemap at another address. Either can do the job. Two at once cannot, because nobody knows which one is maintained.
Google's limit is far higher, at 50,000 URLs or 50 MB per sitemap file, so size is rarely the issue on a B2B site. Google also describes sitemap inclusion as a weak signal for choosing a canonical. A sitemap helps pages get found. It does not settle which version is indexed.
How to check
Open yoursite.com/wp-sitemap.xml in a browser, and any other sitemap address your developer names. Decide which one is the sitemap and switch the other off.
Open the lists inside it and scan the addresses.
What to do
- Remove anything from the sitemap that should not be indexed.
- On launch day, confirm it lists the live address, not staging.
- Submit that one sitemap in Search Console.
7. The robots.txt is the intended one, and blocks nothing needed to render pages
The robots.txt file tells crawlers where they may go. On WordPress it can come from three places: WordPress itself, a plugin, or a real file uploaded to the server. The one that is live is the one that counts.
When there is no file on the server, WordPress generates a virtual robots.txt. It has a general rule that disallows /wp-admin/, allows /wp-admin/admin-ajax.php, and on a public site adds a Sitemap: line.
How to check
Open yoursite.com/robots.txt in a browser and read every line. Or fetch it from a terminal:
curl -s https://www.example.com/robots.txt
Compare it with what your developer says it should contain.
What a failure looks like
- A
Disallow: /underUser-agent: *, left from staging. - Rules that block the folders holding the theme's styles and scripts. Search engines need those to see the page as a visitor does.
- A
Sitemap:line that names the staging address, or a sitemap you switched off in check 6.
If AI search matters to you, the same file decides which AI crawlers may read the site. Our guide to AI crawler access problems covers that, and the layers beyond robots.txt.
8. Pages WordPress creates on its own are handled on purpose
You wrote thirty pages. The site may have several hundred addresses. A WordPress site can produce pages nobody wrote: one for each uploaded image, one for each author, tag and date, and one for every internal search. Most hold a title and a list of links, and little else.
These need a decision each, not a default. Remember from check 4 that core prints its canonical on single posts and pages. As we read that function, archive pages get none from core, so what they output depends on your theme and plugins.
How to check
Ask your developer for a list of every kind of page the site can produce. For each kind, visit one example and view its source.
Look in the sitemap from check 6 for kinds you did not expect.
Decide, for each kind
- Keep and index: it has real content and a reason to be found, such as a category page with an introduction.
- Keep, with
noindex: useful to visitors, not to searchers, such as internal search results. - Switch off or redirect: it adds nothing, such as a page for each image.
A noindex rule and a robots.txt block do not combine. As in check 2, Google has to be able to fetch a page to see its noindex.
9. The main text and links are in the HTML source
WordPress normally sends a complete page from the server. Some page builders, sliders, tabs and "load more" buttons do not. They send a shell and add the text afterwards with JavaScript. A visitor sees no difference. A crawler that does not run scripts sees an empty space.
Google can run JavaScript, and its JavaScript guidance still carries a warning that matters at launch. If the first HTML a page sends contains noindex, Google may not render the page at all, so a script cannot remove the rule later.
How to check
Choose a sentence from the middle of a service page. View the page source and search for it.
Or from a terminal:
curl -s https://www.example.com/your-page/ | grep -c "a sentence from the page"
Do the same for a link in the main menu and a link in the body.
What a failure looks like
- The sentence is on the screen and not in the source.
- Text inside tabs or accordions is missing until you click.
- Menu links are built by a script and are not ordinary links in the source.
The same test matters for AI assistants. See how AI agents evaluate a B2B website for what they can and cannot read.
10. One H1 per page, headings in order, images with useful alt text
Headings are the outline of a page. People using screen readers move through a page by its headings, and search engines use them to understand what each part is about. Themes often break the outline for visual reasons: a logo set as an H1, or a heading level chosen for its size.
How to check
On each page template, search the source for <h1. There should be one, and it should name the page.
Read the headings in order, top to bottom. They should make sense as a contents list, with no level skipped for styling.
In the Media Library, open ten images used on key pages and read their alt text.
What a failure looks like
- Two H1s, or an H1 that is the site name on every page.
- Headings used for size, such as an H4 above an H2.
- Alt text that is empty on an image carrying information, or that is the file name.
The website accessibility checklist has eleven tests, these two among them, with a contrast checker.
11. Structured data comes from one place and matches what the page shows
Structured data describes a page to machines: this is an organisation, this is an article, these are its questions and answers. On WordPress, a theme and one or more plugins may each add their own, and the copies can contradict each other.
Google's structured data guidelines recommend the JSON-LD format. They also say that correct markup does not guarantee a rich result. So the aim here is accuracy, not a visual reward in the results.
How to check
View the source of a key page and search for application/ld+json. Note how many blocks there are and what each describes.
Compare each fact in the markup with the visible page: company name, address, phone number, prices, questions and answers.
What a failure looks like
- Two blocks describing the organisation, with different details.
- Markup for content the page does not show, such as reviews or questions that appear nowhere on it.
- Demo data from the theme still in the markup.
For which types a B2B site needs, with copy-ready code, see schema markup for B2B websites.
12. Speed is checked with real plugins, tracking and consent tools switched on
A speed test on a bare staging site measures a site nobody will visit. The live site will carry analytics, a consent banner, chat, forms and whatever marketing adds in the first month. Test the page as it will run.
WordPress already does some of this work itself. Core has lazy loaded images since 5.5 and iframes since 5.7, and since 6.3 it adds a high fetch priority, the attribute fetchpriority="high", to the image it judges to be the main one. Since 6.8, speculative loading is on by default for logged-out visitors on sites with pretty permalinks. A plugin that repeats one of these adds weight and gains nothing.
How to check
Switch on everything that will run on the live site. A public testing tool cannot get past the password on staging. Before launch, ask your developer to run a lab speed test from a browser that is signed in to staging. Test the home page, a service page and an article, on mobile, several times each, and use the middle result. Run PageSpeed Insights on the live address after launch.
Check whether the main image of each page is being lazy loaded. It should not be.
What to do
- Remove scripts that load on every page and are used on one.
- Fix the largest image on each template first.
- After launch, read the field data once it appears. It describes real visits, and the lab test does not.
Our Core Web Vitals guide for business owners explains the measures, and what a PageSpeed score misses explains why a good score is not the finish line.
13. Forms deliver, spam is filtered without losing real leads, and submissions are tracked
For a B2B website, the form is the point of the whole build. It is also the part most likely to work on staging and fail in production, because email delivery depends on the live domain and the live server.
How to check
Send a real test enquiry through every form, from a personal email address. Do it on staging in the week before launch, and again on the live site on launch day.
Confirm three things for each: the message reached the right inbox, every field arrived, and the submission was recorded in analytics and in the CRM if you use one.
What a failure looks like
- The form shows a thank-you message and nothing arrives.
- The message lands in a spam folder, or goes to the developer's address.
- A field the visitor filled in is missing from the email.
- The spam filter deletes suspect messages. It should hold them for review, so a real lead is never lost.
See how to stop junk leads on your website for a filter that quarantines and does not delete, and how to measure qualified leads from organic search for what to store on every enquiry.
14. Updates, backups and access are set up, and unused plugins and themes are removed
This check is not about search on day one. It is about whether the site is still healthy in month six. A hacked or broken site loses its search visibility quickly, and the cause is usually something left behind at launch.
How to check
Open the Plugins and Themes screens and ask what each item is for. Open the Users screen and ask who each account belongs to.
Ask your developer three questions. Who applies updates, and how often? Where are backups kept, and when was one last restored as a test? Who is told if the site goes down?
The Site Health screen from check 1 also reports the HTTPS status.
What a pass looks like
- No inactive plugins or spare themes left installed.
- No shared logins, and no administrator accounts for people who have left the project.
- Backups stored somewhere other than the web server, with one test restore done.
- A named person responsible for updates.
The First Four Weeks After Launch
Passing the gate means the site is ready to be found. It does not mean it has been. The weeks after launch are when a missed redirect or a stray noindex shows itself.
| When | Look at | What you are checking |
|---|---|---|
| Launch day | Checks 1, 6 and 7 on the live address | The site is open, the sitemap is the right one and robots.txt is the intended one |
| Launch day | Check 13 again: a test enquiry through every form | Email still delivers from the live domain |
| Week 1 | The sitemap in Search Console | It was read without errors, and it lists the live addresses |
| Weeks 1 and 2 | A sample of old addresses | Each still redirects in one step to the right new page |
| Weeks 2 to 4 | The Performance report in Search Console | Impressions and clicks for the pages that had them before |
| Week 4 | Field data in PageSpeed Insights, if there is any | Speed for real visitors, with all scripts running |
| Every week | The enquiry inbox and the spam quarantine | Real leads are arriving, and none are being held by mistake |
The Performance report shows clicks, impressions, click-through rate and average position, and its default view covers three months. Compare like with like: the same pages, over the same number of days, before and after. A page that has dropped to nothing is a reason to recheck its redirect and its noindex.
One Rebuild, Checked Page by Page
FirstChoice Used Auto Parts sells used parts in the United States, and it is one of our WordPress projects. We rebuilt 99 of its pages: 31 part pages, a brands hub and 67 make pages.
Five of these checks were applied to every page, not to a sample. Each of the 99 was fetched after publishing and verified for a correct title, a canonical, one H1, a working form and valid FAQ markup. They are checks 4, 5, 10, 11 and 13 on this list. The site's URLs did not change, so there was no redirect map to get wrong.
The forms had their own delivery test. Every quote form routes to one CRM mailbox, and that was confirmed with a real delivery check. The FirstChoice case study has the full account and the published figures.
Checking page by page is slow. It is also the only way to know, and it is why this checklist asks you to look at several page types and not only the home page.
Four Things You Can Skip
Launch lists grow because nobody removes anything. These four items appear on many of them and are rarely needed on a current WordPress release.
- A second sitemap for its own sake. Core has produced one since 5.5. Add another tool only if you need something the core sitemap does not do, and then switch the core one off.
- A separate tool for lazy loading images. Core has done this since 5.5 for images and 5.7 for iframes.
- A separate tool to preload the next page. Speculative loading has been in core since 6.8.
- Extra structured data added in the hope of a rich result. Google says correct markup does not guarantee one. Mark up what the page shows and stop there.
The rule behind all four: before adding a plugin, check whether WordPress already does the job. Fewer moving parts means fewer duplicated tags, which is where checks 4, 5, 6 and 11 usually fail.
If the site is still at the planning stage, the website design brief questions will get these requirements written down before the build starts.