Get the job done

Decide: nameservers or an A record

Changing nameservers hands all DNS for the domain to Serverlys — simplest, and right for most people. Changing only the A record points the website here while leaving everything else, including email, answered where it is now. If your email is with Google Workspace or Microsoft 365 and you do not want to recreate those records, use the A record.

Write down what you have now

Before changing anything, screenshot the current DNS records — especially MX, TXT and any CNAME. If you switch nameservers without copying these across, email stops. This is the single most common way a domain move breaks a business.

Lower the TTL, then wait

Set the TTL on the record you are about to change to 300 seconds and leave it for at least as long as the old TTL was. Resolvers around the world are caching the old value; this is how you stop them caching it for another day after you make the change.

TTL: 300

Make the change

For nameservers, replace the existing entries with the Serverlys pair. For an A record, set the host to @ and the value to your server IP, then add a CNAME for www pointing at your domain.

A     @     your.server.ip.address
CNAME www   yourdomain.com.

Confirm it resolves here

Check from a device that has never visited the new server — a phone on mobile data is ideal. Your own machine may have the old answer cached for hours regardless of TTL.

Issue the SSL certificate

Only after the domain resolves to us. Certificate issuance validates by looking up the domain, so it cannot succeed before DNS points here. Then raise the TTL back to something sensible, like 3600.

List every sender first

Your mail server, your website's contact form, your invoicing tool, your newsletter platform, your CRM. Each one sends as your domain, and any you forget will start failing the moment you publish a strict policy. This list is the whole job — the DNS records are the easy part.

Publish one SPF record

SPF names the servers allowed to send as your domain. You may only have ONE SPF record per domain; two is a permanent error and worse than none. Merge every sender into a single record.

v=spf1 include:_spf.yourhost.com include:_spf.google.com ~all

Turn on DKIM at each sender

DKIM signs outgoing mail cryptographically so a receiver can tell it was not altered. Each platform gives you a public key to publish as a TXT record at its own selector. Do this for every sender on your list, not just the main mailbox.

Start DMARC in monitor mode

DMARC tells receivers what to do when SPF and DKIM fail. Start with p=none, which changes nothing and only asks for reports. Do not skip this step — going straight to reject is how legitimate mail disappears.

v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com

Read the reports for two weeks

The aggregate reports show every source sending as your domain, including ones you forgot. Fix each legitimate sender until it passes. Anything still failing after that is either misconfigured or is not yours.

Tighten the policy

Once the reports are clean, move to p=quarantine, watch for another fortnight, then p=reject. That final record is what stops other people sending mail that looks like it came from you.

v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com

Install, then set the permalink structure

Settings → Permalinks → Post name. Do this before you publish anything. Changing it later changes every URL on the site, which means every link anyone has shared stops working unless you write redirects.

/%postname%/

Choose HTTPS in both address fields

Settings → General. WordPress Address and Site Address must both start with https://. Setting only one causes redirect loops that are genuinely confusing to debug.

Delete what you are not using

Every default theme except the active one, and every plugin you are not going to keep. An inactive plugin still has code on disk and still needs patching — it is attack surface with no benefit.

Turn on server-side caching before adding a caching plugin

On Serverlys, LiteSpeed caching is configured for you. Install LiteSpeed Cache to talk to it rather than a plugin that implements its own PHP-level cache — running two caching layers that do not know about each other produces stale pages nobody can explain.

Fix images at upload, not afterwards

Set your theme's content width, and stop uploading photos straight from a phone camera. A 4000-pixel JPEG displayed at 800 pixels is the most common cause of a slow WordPress homepage, and no plugin fixes it as well as not doing it.

Set up backups before you need them

Daily backups run at the server level on every Serverlys plan and restores are free. Confirm you know where to find them now, while it is a calm afternoon rather than an emergency.

Confirm the certificate covers what you use

Load the site with https:// explicitly. A certificate issued for example.com may not cover www.example.com unless both were requested. If you use both, both need to be on the certificate.

Redirect http to https at the server

Do it once, at the server or in .htaccess, rather than in a plugin. A plugin redirect runs after PHP has started, which is slower and stops working the moment the plugin is disabled.

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Find the mixed content

Open the browser console on a few pages. Anything reported as blocked or insecure is a resource still requested over http — usually an image URL hardcoded in the database, an embedded font, or a script from a third party.

Fix the database references properly

WordPress stores some settings as serialised data, where a naive find-and-replace corrupts the value and breaks widgets. Use a tool that understands serialisation, or ask us to run it.

Only then consider HSTS

HSTS tells browsers to refuse http for your domain in future. It is the right end state and it is hard to undo — a browser that has seen the header will honour it for the max-age you set. Turn it on once everything genuinely works over https, not before.

Stop and work out when it broke

Restoring to a point after the problem started just reproduces the problem. Check the error log and your own timeline — an update, a publish, a plugin install — and pick a restore point from before it.

Decide what you are restoring

Files and database are separate decisions. A broken plugin usually needs files only; a corrupted post or a bad import needs the database. Restoring both when you needed one loses everything written in between.

Save anything written since

Orders, comments, form submissions and posts created after the restore point will be gone. Export them first if they matter. This is the step people skip and regret.

Restore, then clear every cache

Server cache, plugin cache, and any CDN in front of the site. A restore that appears not to have worked has usually worked fine and you are looking at a cached copy of the broken version.

Find the cause before re-applying anything

You have rolled back to a working state, which means the thing that broke it will break it again if you simply redo it. Reapply updates one at a time on staging.

Find out what your TTL is now

TTL is how long resolvers are allowed to cache a DNS answer, in seconds. 3600 is an hour; 86400 is a day. Whatever it says, that is how long some visitors will keep reaching your old server after you change anything.

Lower it to 300

Set the TTL on the records you will be changing — usually A and CNAME — to 300 seconds. Do not change the record values yet, only the TTL.

TTL: 300

Wait one full old TTL

If it was 86400, wait a day. Resolvers holding the old answer also hold the old TTL, and they will not learn about the shorter one until their existing cache expires. Lowering the TTL an hour before a migration achieves nothing.

Do the migration

Now the change propagates in about five minutes rather than a day, which means the window where some visitors see the old site and some see the new one is short enough not to matter.

Put it back afterwards

Once you are happy, raise it to 3600 or higher. A permanently low TTL means more lookups for every visitor and slightly slower first connections.