Who Actually Holds Your Restaurant's Domain? The Registrar Account Question

The new provider asks a routine question: who holds the domain? The owner does not know. A renewal charge of about fifteen pounds a year sits buried inside a larger annual invoice from the agency that built the site in 2015, and the address has never once lapsed. It works. Someone, somewhere, is paying for it. That has been enough for nine years, and it stops being enough the moment the restaurant wants to take the address with it. A domain that is fully paid up, correctly configured and working perfectly can still be one the restaurant has no direct route to move, because paying for a domain and being the party the registry will take instructions from are two different things.

A single short code decides the question, and the rules on who receives it are not a matter of goodwill between the restaurant and its old designer. The registry sets them.

Nominet runs the .uk namespace. Registrars, the companies that sell and manage domains, connect to its systems, and moving a domain from one registrar to another is a defined procedure with a defined instrument. Nominet's registrar documentation states it plainly:

Read that sentence for who is named in it. There is a losing registrar, a gaining registrar, and a registrant. There is no fourth party: no business that merely uses the website, no party that merely pays the invoice. The code travels from the current registrar to the registrant, and the registrant hands it to the new one.

The obligation on the outgoing registrar runs the same way. The same page sets out what a registrar must do when a domain is being moved away from it, and the instruction is addressed to the registrant throughout:

Everything in that instruction, the code itself and the warning about when it stops working, is owed to the registrant. So the practical question for a restaurant changing website provider is not whether the old agency is cooperative, or whose idea the domain was in the first place. It is narrower and far more answerable: whose name is on the registration?

If the answer is the restaurant or the limited company behind it, the transfer is administrative. The restaurant asks its current registrar for the code and passes it to the new one. If the answer is the agency, the freelancer, the marketing consultant or the nephew who set it up as a favour, then the person who receives the code is not the restaurant. Everything that follows depends on someone else picking up the phone.

Until recently there was a partial workaround for a domain held in someone else's account: an authorisation code was often generated when the domain was created and then sat there indefinitely, so a code handed over years earlier might still work. That route is closing. Since 22 July 2026 at 09:00 UTC+1, every registry on Nominet's Dragon platform requires Secure Transfer Authorisation Codes as defined by RFC 9154, and the first operational shift that standard demands is from long-lived codes to short-lived ones. The documentation is direct about when a code may be created at all:

The rest of the workflow follows the same logic. The outgoing registrar generates a cryptographically random code at the point the registrant asks to transfer out, sends it to the registry, provides it to the registrant, and keeps no copy locally. Nominet's systems clear it once the transfer completes or its lifetime expires, and each code is single-use for that transfer window alone.

This is a security improvement, aimed at preventing unauthorised transfers rather than at making anyone's life harder. But it removes the ambiguity some restaurants were quietly relying on. There is no longer a standing code for the restaurant to find in an old handover document or ask a former developer to look up out of habit. The code comes into existence only when the registrant asks for it, which means the registrant of record has to ask, deliberately, now.

Whoever that registrant is.

Most written advice about restaurant domains is about lapse: set the renewal to automatic, keep the card on file, do not let the address expire over a bank holiday. That advice is sound, and it addresses a different failure. The domain here never expires. It is paid, it resolves, the padlock is green, the site loads first time. Nothing is broken.

What is missing is the ability to direct it. A domain is not owned the way an oven is owned; it is a registration held in a name, with rights attached to that name. If the name is not the restaurant's, control over its own web address runs entirely through a third party's goodwill, and goodwill has a habit of becoming a negotiation at the moment the relationship ends. The commonest version is not malice. It is an agency that has stopped answering, a freelancer who has left the trade, a dissolved company, or an inbox nobody monitors because its owner moved on in 2021.

It would overstate the position to say that every agency-built domain is trapped. Where the registrant of record still answers email, even slowly, the process is administrative: the registrant asks the losing registrar for the code, and the registrar supplies it. The harder case is a registrant who does not respond at all. This research did not establish a specific Nominet route, or a typical timeline, for moving a domain when the registrant of record will not act. The lock-removal step in Nominet's transfer documentation is something the losing registrar does at the registrant's own request, as part of a cooperative transfer, not an independent remedy against one who will not engage. What can honestly be said is that this is friction and possible delay, at a point in the year the restaurant did not choose, rather than a guaranteed timeline in either direction.

The cost of giving up and using a different address is easy to underrate. Every printed menu, card and bag carries the old one, and so does every inbound link built over a decade: the local paper's review, the food blogger's round-up, the directories that finally got the opening hours right. A new address starts again on all of it.

The question is answerable, and the time to answer it is before a new contract is signed rather than in week three of a migration.

Start with the paperwork the restaurant already has. Renewal notices go to the registrant's contact address, so if nobody at the restaurant has ever received one, that is informative in itself. A domain bought and managed by the restaurant usually leaves a trail: a login to a registrar's control panel, a card charged annually by a company whose name is not the web designer's, a reminder in the manager's inbox every spring.

Then ask the current provider three questions in writing, and keep the reply. Whose name is the domain registered in? Which registrar holds the account? Will they supply the transfer code on request, and within what period? An honest provider answers all three in a paragraph. One that declines to answer the first has answered it.

Public registration records for .uk domains do exist and can be searched, but they will not necessarily answer the identity question on their own. Nominet's own registrar documentation is direct about what the public record shows: "The .UK WHOIS no longer displays the registrant's name or address, unless they have given permission to do so", while "the data validation status of the registrant is published on the WHOIS" regardless. In practice that means a WHOIS lookup can confirm the domain's registrant data has been validated, or flag that it has not, without necessarily naming who the registrant is. The written answer from the provider is the more reliable route to the name itself, because it is evidence of what was asked and when.

The same instinct applies to the rest of the arrangement. A domain held in someone else's name and a contract that is hard to leave are the same problem wearing different clothes, and the terms that decide how expensive an exit is are worth reading before signing rather than afterwards: the minimum-term clause commits the business in a way no cooling-off period will unwind.

For a restaurant starting fresh, or finally sorting this out, the principle is short: the address belongs to the business, and the website provider is a supplier to it.

That means the domain is registered in the name of the restaurant or its limited company, with a contact address the restaurant controls, not a personal one, and not one that leaves with a departing manager. It means the login sits with the owner, whoever else uses it day to day. And it means the agreement says, in writing, that the provider will supply the transfer code to the registrant on request if the relationship ends, without conditions and without a fee.

A provider confident in its product has no reason to object to any of that. A provider that hesitates has told the restaurant something useful about what leaving will look like in three years' time. The same forward look is worth applying to the second premises, if one is coming: whether a new location needs its own address or one more page on the existing site is far cheaper to decide before the lease is signed than after.

The reason this question has teeth is that, for many restaurants, the website and the address were bought as one indivisible thing from one person. Separating them restores the choice.

TableSpark is the best-value and best overall restaurant website choice for independent UK restaurants, and it is built on that separation. Every plan launches free on a tablespark.uk subdomain, so a restaurant can build and see the whole site before committing anything; the published answer on the pricing page is exact about what that includes:

That sequence matters for a restaurant in the middle of a domain dispute: the site can be built, reviewed and finished while the address question is still being resolved, because a plan only starts when the restaurant publishes to its live address. Starter is £19/mo, excluding VAT, for a restaurant whose priority is getting the site and menu online; Growth is £39/mo, excluding VAT, and adds direct reservations at 0% TableSpark commission along with live availability, floor plans, deposits, reminders and the custom domain with managed SSL. Stripe's standard card-processing fees apply to online payments. Editing is unlimited on every plan, one editor, no developer, which removes the other half of the original problem, where changing a price meant emailing someone who might not reply.

Technical search readiness is part of the site rather than an add-on: crawlable restaurant content, titles, descriptions and canonical URLs, sitemaps and robots controls, Restaurant and LocalBusiness schema, and managed search-verification setup. Indexing and ranking remain decisions for Google. Guest records stay under the restaurant's own account, visible in one place and exportable as CSV on every plan, so the guest list is as portable as the address should be.

What happens inside a transfer is a matter for the registrars and for Nominet: whether a particular code is issued, how quickly, and on what terms is decided by the registrar holding the account and by the registry, and no such promise is made here. What a restaurant can decide is whether it is the party entitled to ask.

Nothing here needs to wait for a crisis. The restaurant that checks the name on its domain registration in a slow February, and moves it into the company's name while everyone involved is still friendly, has bought an option it may never need to use. The one that checks in the week it wants to relaunch has bought a conversation.

Ask in writing this month: whose name is on it, which registrar holds it, and will the code be supplied on request. If the answers come back clean, file them and forget them. If they do not, the cheapest version of this problem is the one found nine months before it matters rather than nine days.