You Can't Reach Your Web Guy. Here's How to Take Back Your Domain, DNS, Hosting and Content.

You own your website only if you control five things: the domain registrar account, the DNS zone, the hosting account, your GA4 and Search Console properties, and the source files. Most owners control none of them. If your developer has gone quiet, you can verify all five yourself in about twenty minutes, and you can start recovery today without their cooperation. Here is the order to do it in.

"My website" is five assets, held in five places, often on five different accounts. A developer who set everything up on their own logins isn't necessarily malicious — that's the fastest way to launch a site. It only becomes a problem the day they stop replying.

None of these need the developer. All of them are public or already in your inbox.

1. WHOIS, for who holds the name. ICANN Lookup for a .com, CIRA's WHOIS for a .ca. Read the registrar name and the expiry date first — those are always public. Registrant details are redacted on most domains now, so if you can't see a name, that is itself the finding: nothing public proves the name is yours, and you have no login to look behind it.
2. Nameservers, for who controls DNS. The same record lists them. If they belong to a host you've never had a password for, that party decides where your site and your mail resolve.
3. GA4 roles. Admin → Property access management. Your own address should read Administrator. If it isn't listed at all, you're a guest in your own data.
4. Search Console roles. Settings → Users and permissions. Your address should read Owner, not Full or Restricted. Only owners can add or remove other users — including removing the developer.
5. Hosting and source files. Is the card on file at the host yours? Then ask one thing by email: send me the repository URL, or a zip of the site files. A one-line answer means you're fine. "It's all on the server" means the only copy of your business sits on a machine you don't control.

whois yourdomain.ca         → registrar, expiry, registrant
dig NS yourdomain.ca +short → who answers for your DNS
dig A  yourdomain.ca +short → what answers for the site (a CDN in front will mask the real host)
dig MX yourdomain.ca +short → where your email goes

No terminal? Every one of those is a free web lookup — ICANN Lookup or CIRA WHOIS for the first, any public DNS lookup tool for the other three. Same answers, no install. Anything you couldn't answer is a hostage, and that list is your recovery plan.

Two things before you escalate. Check the expiry date and whose card renews it: a domain that lapses mid-negotiation turns a recoverable problem into an auction. Then put the request in writing, dated — one email naming exactly what you want transferred, and by when.

A normal transfer needs the domain unlocked and an auth code, both from inside the account. If you can't get in, you have four routes.

• Account recovery. Check the registrant and admin email on the record. If it's an address you control, even an old one, run the registrar's password reset. Worth trying first: the reset goes to the address on the record, not to them.
• Ask for a push, not a transfer. If you can get one cooperative reply, moving the domain to your own account at the same registrar is a same-day internal change. No unlock, no auth code.
• Registrant change or dispute. Every accredited registrar has a process for a rightful registrant locked out of their own name. Send the whole package at once: proof you paid for registration and renewals, business documents matching the name, the original invoices, and email showing the domain was bought on your behalf. A partial claim gets answered by a template.
• Escalate above the registrar. Most Ontario businesses are on a .ca, which puts CIRA, not ICANN, at the top of the escalation ladder — CIRA runs its own registrant transfer and dispute procedures. For .com and other gTLDs, ICANN takes complaints about registrars that break their own policies.

Expect a 60-day lock after any registration or registrant change; a push inside the same registrar isn't blocked by it. If the developer is reachable and simply refusing, or a registrar rejects your evidence, that's the point where a lawyer is the right call. We build websites; we don't give legal advice, and this isn't it.

Nameservers are set at the registrar. Change them and DNS follows. That's the whole lever — and it's also the step that breaks businesses, so do it in this order.

1. Copy the whole zone first. Every A, CNAME, MX and TXT record, including SPF, DKIM, DMARC and any verification strings. Screenshot it, export it if the provider allows.
2. Move nameservers to a provider on an account in your name. Not your new developer's account. Yours.
3. Re-create every record exactly, then change nothing else that day. A roofing company that switches nameservers without carrying MX across doesn't lose its website — it loses every quote request sitting in its inbox.
4. Verify mail is flowing before you touch where the website points.

Once you hold DNS, one of the bigger locks opens quietly: verify a domain property in Search Console with a single TXT record, and Google hands you the search history it already had — up to roughly 16 months of it — without anyone's permission.

You don't need the old host's cooperation to build the replacement. The old site keeps serving customers the whole time, and cutover is one DNS change at the end.

1. Crawl the live site and capture every URL. A crawler finds what the sitemap forgot, and that list becomes both your content inventory and your redirect map. The rendered HTML is public — you can read it without anyone's permission.
2. Build on a preview URL. Nobody sees it, nothing breaks, no deadline pressure from a site that's already down.
3. Map old URLs to new ones. Same path where you can, a 301 where you can't. This is exactly where relaunches bleed — see what causes a post-relaunch traffic drop and how WordPress-to-static migrations preserve rankings.
4. Cut over. One record change, and it lands as fast as your TTL allows — drop the TTL a day ahead so it lands fast, and it's reversible the same way.

We've done the ugly version: a business rescued from a roughly 1,200-page spam infestation, cleaned, rebuilt, re-ranked, and moved onto an architecture with no database and no plugins left to reinfect. We don't name that client, and we don't name any client in a sensitive situation — if we'd trade their name for your signature, we'd trade yours too. If that's where you are right now, start with what to do when a WordPress site gets hacked.

Different assets, different answers. Don't apply one verdict to all five.

• The domain: always recover. Backlinks, citations, review profiles, signage and word-of-mouth are all attached to that one string. A new domain starts at zero.
• Analytics: recover if one email can do it, otherwise start fresh today. Every week you wait is a week of data you'll never have.
• Hosting: rarely worth the fight. You aren't recovering a server, you're recovering what's on it.
• Content and code: the real judgment call. Recovery gets you an old site you probably didn't like; a rebuild gets you an asset you own outright. The moment recovery becomes a negotiation on a deadline nobody controls, rebuilding wins.

Cost drivers, if you're weighing it: page count, how much copy can be lifted versus rewritten, how many forms and integrations get re-wired, how many URLs need mapping, and whether the design exists in any editable source at all. A ten-page HVAC site and a pest-control site with a page per town are not the same conversation. Rough test: the week the chase starts costing more than the rebuild, stop chasing.

Some of this is gone. Plan around it instead of chasing it.

• Content behind a login. The public pages are recoverable — they're on the internet. Drafts, form submissions and customer records may not be.
• Page-builder markup. Content stored as shortcodes or blobs of JSON isn't portable. You'll recover the words and lose the layout. Expect to rebuild the page, not paste it.
• The design source. Without the layered files, the design exists only as pixels, and a screenshot is a reference, not a source. Fonts and stock photography licensed to their account don't travel either.

None of this is inevitable. It happens because so much of the web stores your business inside somebody else's software. When a site is plain files — content in text, templates in a repository you own, no database and no plugins — "give me my website" is a folder someone can email you in a minute. That's the reason we build the way we build, and the proof is clickable: thecritterguy.ca, batsandwildlife.ca and cottagehero.ca are brands we build. Open any of them, run Lighthouse yourself, and note there's no plugin stack behind them. The architecture is explained on the websites service page.

Ownership is a set-up decision, not a rescue operation. Whoever builds your next site — us or anyone else — insist on these before work starts.

• The domain is registered in your business name, on your email, on your card. Contractors get access, not ownership.
• You are Owner in Search Console and Administrator in GA4 from day one. Everyone else holds a role you can revoke.
• Hosting is billed to you, in your name.
• Source files live in a repository or storage account you can open without asking.
• A written offboarding line: what gets handed over, in what format, within how many days of the engagement ending.

Then ask one question and watch the face: if we part ways, what exactly do I keep, and can this site run without you? A straight answer is the whole test. It's the same filter that separates a real shop from a reseller in how to hire an SEO company — the questions are boring, and the wrong answers are loud.

Send us the domain and we'll tell you what a public lookup shows: registrar, nameservers, host, and what your current site is actually built on. No obligation, no sales rep, no discovery call to book a discovery call. Tell us what you want to rank for, and the people who'd do the work reply.