Why we ask for the keys

We ask for four things: where your domain is registered, what answers when someone types your address, the server the site runs on, and the site’s own admin login.

It is fair to get uncomfortable at that. You have likely been asked for a website password before by someone who only ever changed text on a page. Now a marketing company wants the lot.

The honest answer is not about efficiency.

Almost every agency promises to market your website. Almost none states the promise underneath it: that they will be able to see what is actually happening. Not what a dashboard reports. What happened.

Those are different things more often than anyone admits, and the gap is only visible from inside. Seeing requires access. Access requires ownership to be settled first, because you cannot hand over what you cannot prove you hold. And settling ownership surfaces whatever has been quietly broken.

That sequence is this whole page.

Four layers, four different keys

A website is not one thing you have one password for. It is four separate systems stacked on top of each other, each with its own login, each holding evidence the others cannot see.

The one almost everybody hands over first is the bottom row. It is also the one that sees the least.

A site admin login shows you the pages and the form entries. It cannot tell you that your email is about to stop working, because that lives in DNS. It cannot show you the visits that never loaded a tracking script, because those only exist in the server log. It cannot prove you own the name, because that is at the registrar, and the registrar is usually the account nobody can find the login for.

That last one matters more than it sounds. A domain is the only asset in the stack that is genuinely yours and genuinely portable. Everything else can be rebuilt. If the name is registered to an agency that has stopped returning calls, you do not have a marketing problem, you have a hostage situation.

So the request is not “give us everything.” It is: let us see each layer once, confirm who holds it, and write it down.

What looking actually finds

The reason we insist on this is not theoretical. Access is how you find the failures that never announce themselves — and in our experience that is most of them.

Systems under-report far more often than they break. Consider three you almost certainly have running right now:

• A content delivery network sits in front of your site. It answers a large share of requests itself, and those requests never reach your server’s log at all. Your log is not wrong. It is partial, and nothing in it says so.
• A security rule filters rows out of a database result. The query returns ten records and a success status. There were fifteen. Nothing in the response mentions the five that were withheld, because from the database’s point of view it did exactly what it was told.
• A dashboard reports a row count that is not a count. Some systems keep a running tally as a side effect of write activity and reconcile it later during housekeeping. On a table that housekeeping has not visited, the number can sit wrong for months. We have seen a table report 141 records and hold 134.

Each one returns less, with every appearance of having returned everything, and nobody is notified, because from the outside nothing went wrong.

A thing that fails loudly gets fixed on the day. A thing that quietly returns less gets built on for a year — and the cost is not the wrong number, it is every decision made downstream of it.

None of those three is visible from the outside. All three are obvious within an hour of having access.

A receipt, and a model of a receipt

Here is the whole argument in one comparison, and it needs no technical background at all.

When somebody fills in the contact form on your site, the form software writes a row into your database with a timestamp. That row exists because the submission happened. It is a receipt.

When somebody fills in that same form, your analytics records a conversion if the tracking tag fired, and the script loaded, and no ad blocker stopped it, and the visitor did not leave too quickly, and the tag was configured correctly in the first place. That is not a receipt. It is a model of a receipt, assembled from things that mostly go right.

They disagree. They disagree in one direction — analytics is lower, always — and the database is the one that is right.

This matters for a specific, expensive reason. If you judge which services and which towns are worth advertising in by a number that is systematically low, and low by different amounts depending on what browser your customers use, then you are not measuring demand. You are measuring tag reliability, and then spending money on the result.

The receipt is already sitting in your own database. It has been there the whole time. Reading it requires access to the application layer, which is exactly the access that sounds excessive until somebody explains what it is for.

The part we say out loud

Everything above is an argument for moving your site somewhere it can be seen properly. So here is the other half, because a page that only sold you the upside would be selling you risk.

A migration is the most dangerous moment in a website’s life.

The reason is that a domain name does far more than point at a website. On a typical small-business domain there are around seventeen DNS records. Exactly one of them is the website. The rest are email routing, sender authentication, certificate validation and vendor verifications.

Move the name carelessly and the site comes up fine. It looks like a clean cutover. Meanwhile your email has stopped arriving, and nothing announces that either — mail does not bounce loudly to you, it fails at the sender’s end, to people you were never going to hear from.

This is the same failure as everything else on this page. The visible thing works. The invisible thing has stopped.

So the migration is not the valuable part of the work. The audit is. The migration is simply the event that forces the audit to happen, because you cannot move a name safely until somebody has written down all seventeen records and what each one is for.

Most of that value is available without moving anything at all. If you want the audit and not the migration, that is a completely reasonable thing to buy, and we will tell you so.

It is your data

The reason to settle all of this is not tidiness. It is that there is an asset sitting in your business that almost nobody uses, and the only thing standing between you and it is access.

Every one of these is first-party. Yours, recorded by your own systems, not licensed back to you by a platform:

• The server log, which records every request including the ones no analytics tag ever saw
• The form database, which holds an actual receipt for every enquiry, with a timestamp
• The job and estimate records, which tell you what people actually bought, not what they clicked
• The addresses those jobs went to, which describe your real service area rather than the one on the About page
• The content and the photographs, which are yours outright

These are better than the platform’s version of the same thing. Not a substitute — better. The platform’s figures are sampled, modelled, thresholded and increasingly withheld in the name of privacy. Yours are the events themselves.

And they are more durable. Analytics platforms discard history on a retention schedule and change their minds about metrics between versions. Search tools revise the past. Your own database does none of that; a row written in 2024 says the same thing in 2029.

The only reason this asset goes unused is that nobody ever got the access to look at it. That is the whole of it. Not a technology problem, not a budget problem — four logins nobody could find, and no one willing to spend the unglamorous week it takes to chase them down.

It is your data. We would like to be the people who finally go and read it to you.

How to hand access over without handing over everything

You should not give anyone your passwords, including us. Every system in that four-layer stack has a better mechanism, and asking for it is a fair test of whoever you are hiring.

Three rules behind that table, in plain terms.

1. Delegated access beats a shared password. A shared password cannot be audited and cannot be withdrawn without changing it for everyone, so in practice it never gets withdrawn at all.
2. A key per operator beats one key for the team. The question “who ran that” should have an answer, and offboarding should be one click rather than a rotation everybody has to absorb.
3. A scoped token beats shell access. Most work needs one narrow capability. Handing over the whole machine to get it is how a small mistake becomes an outage.

And the one to insist on regardless of who you hire: keep the domain registered in your own name, on an account you control, with the renewal on a card that does not expire quietly. Delegate everything else freely. That one stays yours.

If an agency will not work within these, that tells you something useful before you have paid them anything.