A client rings me because the shop has gone dark.
Not “a bit slow.” Dark. Checkout dead. Homepage blank. Or worse — the site still loads, but customers land on a “this domain is for sale” parking page from a registrar they’ve never heard of.
My first instinct used to be the WordPress login. Check the plugins. Blame the last update. Open the host panel and poke at PHP versions.
These days I ask something quieter first.
Who owns the DNS?
Not who thinks they own the domain. Not who pays the hosting invoice. Who can actually change the nameservers and the A records when it matters.
That one question has saved me more weeks of guessing than any clever debugging trick I know.
Domain, hosting, and email are three different doors
Here’s the shape I see over and over on UK WooCommerce shops.
The domain was registered five years ago at one registrar — often under the founder’s personal email, sometimes under an agency that left. Hosting sits with a managed WordPress host or a cheap VPS the previous developer preferred. Email lives somewhere else again: Google Workspace, Microsoft 365, or a free mailbox that somehow still receives the renewal notices.
Three vendors. Three logins. Three renewal dates. One live till that depends on all of them lining up.
When something breaks, people assume “the website” is one thing. It isn’t. The site files live on the host. The name that points customers there lives at the registrar (or at Cloudflare, or at whoever holds the nameservers). The mailbox that owns half the accounts may not live on either.
If you start fixing in the wrong door, you burn a day proving a theory that was never the problem.
What went wrong — a week of the wrong door
A shop owner contacted me after a redesign. New theme. New checkout. Staging looked fine. They flipped DNS… and the live site showed the old homepage for some people and a certificate error for others. Support tickets piled up. The agency who’d built the redesign swore the host was fine. The host swore the DNS hadn’t propagated. The client just wanted orders back.
Nobody could answer a basic question: who can edit the records right now?
It turned out the domain was still on the old registrar, nameservers pointed at a CDN account under the previous developer’s login, and the host’s “point your domain here” guide had been half-followed twice. Email MX records had been nudged during the same change, so transactional mail started bouncing while we argued about caching.
I spent the first day not touching WordPress at all. I spent it establishing custody: registrar login recovered via the business email trail, CDN account transferred, nameservers documented, MX checked against the Workspace admin, A and CNAME records written down before anyone changed another thing.
The redesign wasn’t broken. The map to it was.
That week taught me a habit I still use. Before I open the theme customiser on a broken shop, I want a one-page picture of who controls DNS — and whether that person is in the room.
What I ask now before I touch anything
When a Woo or WordPress site misbehaves in a “is it even pointing at the right server?” way — SSL loops, intermittent old content, sudden parking pages, mail that stopped after a migration — I slow down and ask:
- Who is the registrar, and whose email owns that account?
- Where are the nameservers pointed (registrar default, Cloudflare, host DNS, something else)?
- Who can log in and edit A, CNAME, and MX records today — not “we used to”?
- Is hosting a separate company from the registrar?
- Where does shop email actually live, and did anyone change MX while “just updating the site”?
- Is there a CDN or proxy in front that caches DNS or SSL decisions?
I write the answers down. If half the answers are “not sure,” day one is mapping — not feature work. I say that out loud so the client knows I’m not stalling. I’m stopping us from editing the wrong panel for three days.
I also ask who pays the invoices. Billing emails are often the only reliable trail when passwords vanished with a previous freelancer.
Why this matters more on WooCommerce
A brochure site with wrong DNS is embarrassing. A WooCommerce shop with wrong DNS is lost orders, failed webhooks, and Stripe callbacks hitting a server that isn’t yours anymore.
Subscriptions renew against the wrong host. Abandoned-cart emails never leave. Payment gateways still think the old URL is live. Caching layers serve a mix of old and new until nobody trusts what they’re looking at.
And because DNS, hosting, and email are split, three different support desks will each say “works from our side.” They’re often all telling the truth — about their door. The problem is the handoff between doors.
So I treat DNS ownership as part of the access pack, same as hosting and Stripe. If we’re taking over a store, “who owns the DNS?” sits next to “who has the host login?” on the first checklist. I’ve written about handovers with zero logins before; this is the quieter cousin of that mess — you have logins, just not for the layer that’s actually broken.
The practical takeaway
Before you — or anyone you hire — touches a broken Woo or WordPress site, establish who controls DNS. Separate that from who controls hosting. Separate both from where email lives.
Don’t assume the host panel is the domain. Don’t assume the domain login can change MX. Don’t start a migration, an SSL fix, or a “quick DNS tweak” until one named person can open the records and you both agree what “correct” looks like.
Five minutes of ownership clarity beats a week of clever guesses in the wrong dashboard.
Need a hand?
If you want a WooCommerce developer who asks where the keys are before he starts turning them, hire me — fixed-price quote, no obligation.
Written by Connie, an AI, from Neil Matthews’ notes, archive, and direction. Neil directed and edited this piece. He did not write these words. Augmented publishing by Neil Matthews.