The go-live checklist

Before you start

This assumes the site itself is finished and sitting on Hostworld WordPress hosting or standard cPanel hosting, and that the domain either already points here or has just been moved to Hostworld's nameservers. If you haven't pointed the domain yet, do that first: at your registrar, set the nameservers to ns1.serverworld.uk, ns2.serverworld.uk, ns3.serverworld.uk and ns4.serverworld.uk, then wait for it to propagate before you rely on anything in this checklist, particularly the SSL step.

You'll need your cPanel login, your WordPress admin login, and access to edit .htaccess either through cPanel's File Manager or FTP. One general piece of advice before you start ticking boxes: do the SSL and redirect changes at a quiet time, not five minutes before you post the launch link. Both can cause a brief window where the site behaves oddly while the change settles.

Step 1: Force HTTPS, don't just install the certificate

On cPanel hosting, SSL is normally handled by AutoSSL rather than a certificate you generate and upload yourself. It runs automatically in the background every few hours, but you don't have to wait: in cPanel, go to SSL/TLS Status, select the domain and click Run AutoSSL to install it immediately.

If it fails, the most common cause is an existing certificate in the way. AutoSSL will not overwrite a certificate that's already installed, including an old self-signed one or an expired one left over from a previous build. The fix is:

1. In cPanel, go to SSL/TLS and click Manage SSL Sites.
2. Find the domain and uninstall the existing certificate.
3. Return to SSL/TLS Status and click Run AutoSSL again.

Removing a certificate leaves a short gap with no valid HTTPS on that domain until the new one issues, which is another reason to do this at a quiet time rather than while you're telling people to visit the site.

A padlock is not the finished job. Having a certificate installed doesn't stop a visitor landing on the plain http:// version if they type it or follow an old link. You need a redirect that sends every request to the secure version, so the certificate is actually doing something rather than sitting there unused.

There's no undo needed here beyond the redirect rule itself, which is covered next: if forcing HTTPS breaks something, you remove that rule and the site falls back to serving both versions, which isn't broken, just untidy.

Step 2: Pick www or non-www, and redirect the other one to it

example.com and www.example.com are, technically, two different addresses. Left alone, search engines can index both and split your results between them instead of treating the site as one thing. Neither version is more correct than the other, it's your choice, but you need to pick one and make everything point at it consistently.

The usual fix is a single rewrite rule in .htaccess. Before you touch it, copy the existing file somewhere safe. A wrong or duplicated rewrite rule can create a redirect loop that takes the whole site offline, and having the original to drop back in is the fastest way out of that.

To force the non-www version:

RewriteCond %{HTTP_HOST} ^www\.example\.com$ [NC]
RewriteRule (.*) https://example.com/$1 [R=301,L]

To force www instead, reverse the condition and target:

RewriteCond %{HTTP_HOST} ^example\.com$ [NC]
RewriteRule (.*) https://www.example.com/$1 [R=301,L]

Two details that get missed: it has to be a 301 (permanent), not a 302, or search engines won't fully consolidate the two versions into one. And your canonical tags and XML sitemap need to point the same direction as the redirect. If you've forced non-www but your sitemap or SEO plugin is still generating www URLs, you're sending mixed signals, which undoes the point of doing this at all.

To check it worked, visit all four combinations, http:// and https://, with and without www, and confirm they all land on the same final address with a single 301. A redirect-checking tool will show you the status code and whether there's a chain of redirects rather than one clean jump.

Step 3: Make sure WordPress isn't hiding the site from search engines

Sites are often built with search engines deliberately shut out while they're in progress, and that setting is easy to forget once the site is actually ready. Check it in the WordPress dashboard: Settings > Reading > Search Engine Visibility. If the box labelled "Discourage search engines from indexing this site" is ticked, untick it.

What that box actually does: WordPress edits robots.txt and adds a noindex tag to your pages. You can check the current state yourself by right-clicking the live site, choosing View Page Source, and searching for meta name='robots'. If you see noindex, nofollow in there, search engines are still being told to stay away, whatever the dashboard setting shows.

It's worth knowing this is a request, not a lock. Reputable crawlers like Google and Bing respect it, but not every crawler will, and it never stops a person visiting the URL directly or another site linking to it. It only affects indexing.

If you're running Yoast SEO or All in One SEO, check their settings too, separately from the WordPress core one. Yoast: SEO > Settings > Site features > Site visibility. All in One SEO: Search Appearance > Advanced. Either plugin has its own discourage-indexing toggle, and it's entirely possible for the WordPress core setting to look fine while the plugin is still quietly telling Google not to index the site. That's a silent failure that's easy to miss on a launch-day check.

Step 4: Send yourself a real enquiry through the contact form

Don't just check the form looks right, submit it. Fill it in as a customer would, using an email address you can check, and confirm the notification actually arrives, including a look in spam. If nothing turns up, check the address the form is configured to send to, and check it against whatever mailbox is meant to receive it. Do this after your domain's DNS and mail settings have settled, since a form that "worked" during testing on a half-configured domain can silently stop once things change.

Step 5: Confirm what's actually backing the site up

cPanel's built-in backup tool is manual. Nothing gets backed up on its own unless something has been separately scheduled on the account. Don't assume "backups running" is true because cPanel has a backup feature, check what's actually set to happen, and if you're not sure, open a support ticket and ask what's scheduled.

There are two very different outputs from cPanel's backup tool, and it matters which one you're relying on:

• Full backup: covers the whole account, but the archive it produces can't be restored by you. It's built to be restored by a server administrator, so if you ever need one put back, that means opening a ticket, not clicking restore yourself.
• Partial backups (files, database, email): these you can restore yourself from inside cPanel.

Whichever kind you're taking, remember a backup only reflects the exact moment it was made. A backup taken on launch day won't include anything you write, upload or change afterwards, so this isn't a one-off tick, it needs repeating.

Two things that quietly break backups: an account sitting near or over its storage quota can cause the backup to fail because it can't write the files it needs, so check your usage isn't maxed out. And once you've taken and verified a full backup, don't leave it sitting in the account indefinitely, download it and store a copy somewhere else, your own machine, an external drive, or object storage, and free up the space on the server.

Step 6: Check a real visitor sees a real site

Visit the live URL yourself, not the admin area, and look at it the way a stranger would. Confirm it's showing actual content and branding, not the default WordPress "Hello World" post, a theme's demo homepage, or placeholder images and lorem ipsum text left over from the build. This is the kind of thing that's obvious once you see it and easy to miss if you've only been looking at the dashboard.

Step 7: Check it on mobile, with a tool that still exists

Google retired the Mobile-Friendly Test, the Mobile Usability report and the associated API in December 2023, so any checklist that still tells you to run that tool is out of date. There's no single like-for-like replacement. Google points to Lighthouse, which covers more ground than the old test did, including performance metrics like Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift, and PageSpeed Insights or the Core Web Vitals report in Search Console cover related but different parts of the picture.

In practice, the simplest check is still to open the live site on an actual phone and see whether it works: whether text is readable without zooming, whether buttons are easy to tap, and whether anything overlaps or runs off the edge of the screen. Use Lighthouse if you want the numbers behind that impression.

What next

Once these seven are ticked off, the site is genuinely ready to have people sent to it, not just built. If you haven't already, check that email for the domain is working correctly alongside the site, and if backups need scheduling properly rather than left to a manual click, that's worth sorting now rather than after something goes wrong. Our cPanel guides cover backup scheduling and certificate management in more detail, and if anything here doesn't behave the way this checklist says it should, open a support ticket and we'll take a look at the account directly.