Development · Analysis

Five checks after a WordPress launch that protect your rankings

Most post-launch SEO problems are quiet: a setting left on, a cache that still serves the old page, a layout nobody tested on a phone.

By Dean Cruddace · Published · Read 5 min · Last reviewed

New to this?How to check a WordPress site before launch for SEOLearn it step by step: what it is, why it matters and how to do it on your own site.Open the beginner guide →

Key findings

  • WordPress's "Discourage search engines" setting adds a noindex,nofollow tag, and it also switches off the built-in XML sitemap.
  • A CDN can keep serving the old version of a page, to visitors and crawlers, for as long as its cache lifetime allows.
  • Google uses the mobile version of your content for indexing, so a desktop-only check is not a launch check.

A launch is the moment a site is most visible and least verified. Developers have usually checked that pages render. SEO needs a different set of checks, aimed at the things that fail quietly and cost weeks of visibility before anyone notices. These five come from rebuilding and launching WordPress sites.

1. The search visibility setting

Staging and development sites should be hidden from search engines, and WordPress has a setting for it: Settings, Reading, “Discourage search engines from indexing this site”. It is easy to leave on when a site goes live. WordPress documents what it does: since version 5.3 it adds a robots meta tag with noindex,nofollow to the page head. There is a second effect that is easy to miss. WordPress’s built-in XML sitemap is enabled only when the site is public, so the same setting switches off /wp-sitemap.xml.

Check it by viewing the page source of the live home page and searching for “robots”, then opening /robots.txt and /wp-sitemap.xml. It takes a minute and it guards against one of the most expensive launch mistakes.

2. Caching in front of the site

A CDN or page cache holds a copy of each page for a set time, which is set by the Cache-Control header. In one rebuild, visitors who were not logged in kept seeing the previous theme on the home page for as long as the cache lifetime allowed, a week as it turned out, while the other pages were served fresh. Crawlers receive the same cached copy as any other visitor.

Check the response headers for the home page and two or three other pages as a logged-out visitor, and look at the Cache-Control value and any cache-status header your CDN adds. For HTML pages, a short lifetime is usually a better trade than a long one, and clearing the cache is part of the launch, not an afterthought.

3. The phone version

Google uses the mobile version of a site’s content, crawled with a smartphone agent, for indexing and ranking, and recommends that the mobile page contains the same content as the desktop one. A design approved at desktop width can hide, collapse or overflow content on a phone: columns that become unreadably narrow, long headings that run under images, spacing sized for a large screen that turns a page into a very long scroll. Check every template at a phone width, not only the home page.

4. Test URLs that cannot change the page

When checking whether a change has gone live, people add a throwaway parameter to the URL to bypass caches. Some parameter names are reserved by WordPress, for example m for a month archive and s for search, and using one of them changes which page is loaded or returns a 404. Choose a name WordPress does not use, such as cb, so that what you test is the page you meant to test.

5. Test as a logged-out visitor, and as a crawler

When you are logged in to WordPress you bypass most caching and see an admin bar, so you are not seeing what visitors see. Test in a private window, and then use the URL Inspection tool in Search Console to see what Google receives for the page. If the two disagree, fix that before anything else.

Other WordPress launch traps

  • Plugins that add their own noindex. An SEO or maintenance-mode plugin can add a robots tag or an HTTP header independently of the Reading setting, so check the source and the response headers, not just one place.
  • Staging addresses in the content. Hard-coded links, images and canonical tags that still point at a staging domain survive migrations. Search the database and the page source for the staging hostname.
  • Canonical tags on the live domain. Every page should declare itself as the canonical version, on the live domain and the preferred protocol.
  • Mixed protocols. Links and resources that still use http on an https site produce warnings and extra redirects.
  • Old addresses. If the structure changed, a redirect map should be in place before launch, not assembled afterwards.

Checking each one, step by step

Search visibility and the sitemap

View the source of the live home page and search for robots. A tag such as <meta name='robots' content='noindex, nofollow' /> means search engines have been asked to stay away. Then open /robots.txt and look for a Disallow: / rule, and open /wp-sitemap.xml to confirm it loads. Google’s introduction to robots.txt is a useful reminder of what the file is for: it tells crawlers which URLs they may access, mainly to avoid overloading a site, and it is not a way to keep a page out of Google.

Cache headers

From a command line, curl -sI https://example.com/ prints the response headers. Look for Cache-Control, and for a header from your CDN that says whether the response was a cache hit. If the home page says a cache hit with a lifetime of days, a rebuilt page will not appear to logged-out visitors until the cache expires or is purged. Repeat for a deeper page, because different page types are often cached differently.

Phone width

Resize a browser window to about 375 pixels wide, or use the device mode in the browser’s developer tools, and scroll through each template. Look for horizontal scrolling, headings that overflow, content that disappears, tap targets that are too small and spacing that makes a page unreasonably long.

The first week after launch

Launch checks catch the quiet failures. The first week catches what they missed.

  • If URLs changed, confirm that old addresses redirect to the right new ones. Google’s guidance on redirects explains that permanent redirects show the new target in search results.
  • Watch Search Console for new errors and for pages that are excluded when they should be indexed.
  • Check the Crawl Stats report for a rise in errors or a drop in requests.
  • Re-run the checks above once the cache has expired, because some problems only appear when a cached copy is replaced.

A launch checklist in one line each

  • Search visibility setting is off: no noindex, sitemap loads.
  • Robots file allows what it should and points to the sitemap.
  • Response headers show a sensible cache lifetime; cache cleared.
  • Every template checked at phone width.
  • Pages checked logged out and in URL Inspection.

Further reading on WordPress launches

Written by Dean Cruddace

Founder of Cultured Digital. Working in SEO since 2001, across independent consultancy, in-house and agency roles, with a focus on technical SEO, strategy and development.

About Dean →