The Restaurant Kept the Address and Changed the Name

That produces not one problem but two, running in opposite directions. A guest who heard the new name from a friend searches it, finds a thin result or nothing recognisable, and concludes the place is new, unreviewed and unproven, while four years of accumulated reviews sit under a name they never search for. A guest who knows the old name finds the old listing, books, arrives, and stands outside a door with a different word on it. Meanwhile the restaurant answers the phone with one name, sends confirmation emails under another, and takes delivery orders under a third. The split doesn't resolve on its own. It lasts exactly as long as the slowest surface takes to be updated, which in practice is whichever one nobody wrote down.

One scope note before the legal material: what follows in this section is the limited-company route. The sole trader running under a trading name has a different route to the same outcome, and that route was not located in this research; nothing here should be read as describing it. Everything after this section is about the guest-facing surfaces, which behave the same way whatever the legal wrapper underneath them is.

A name change in a restaurant feels like a design decision, so it tends to get run as one: the sign, the menus, the Instagram grid, the new logo on the awning. If the trading entity is a limited company, there's a harder edge underneath that, and it's dated. GOV.UK's guidance on making changes to a private limited company is direct about when the change actually takes effect:

The same guidance sets out the two routes, a special resolution, or permission given in the company's articles of association, and then prices each way of filing separately. The online service is the narrower one: it takes changes of name "by special resolution only", and on that route the guidance states:

By post the fee is £30 on either route: form NM01 where there is a special resolution, form NM04 where the articles give permission, and the guidance offers no same-day option on the postal path. That's the useful part for planning, and it's why the sequence matters. The legal identity can flip in a single day on the online same-day filing, for the cost of a moderate wine order. Every guest-facing surface can't. From the morning of registration, the restaurant has a registered name and a website, a listing, an email footer, a set of legal pages and a stack of printed QR cards that all disagree with it, and closing that gap is entirely the owner's job.

The Google Business Profile is the surface most restaurants treat as a form field and most guests treat as the restaurant. It doesn't behave like a form field. Google's own help documentation for editing a profile sets the standard the name has to meet:

Read literally, that's an instruction to do the sign and the listing as one job, not a month apart. Taken at its word, it also leaves no room for the common rebrand fudge of listing both names at once, "New Name (formerly Old Name)", because the thing on the signage is one name.

Two further sentences on the same page shape the timing. The first is that an edit is not a live change:

The second catches owners who assumed a rename was clerical:

"Might" is doing real work in that sentence and it should not be inflated. It's not a guarantee that a rename triggers re-verification, and it's not a promise that it won't. What it means operationally is that the listing change is the item on the list with the longest and least predictable tail, which is an argument for starting it early rather than saving it for the tidy-up. How long Google's review takes, and whether a given edit clears it, are decisions Google makes about its own listing surface; no such promise is made here.

The goal is not speed. It's that at no point does a guest searching either name reach a dead end. A sequence gets you there, and it runs roughly the reverse of the one most rebrands actually follow.

Settle the domain question before anything else. This is the only decision in the list that's expensive to reverse. A restaurant that keeps its existing domain and changes only the name on the pages keeps its whole link history intact and spends nothing; a restaurant that buys a domain matching the new name gets a cleaner match between what the guest hears and what they type, and takes on the work of pointing the old address at the new one. Both are defensible. What isn't defensible is deciding it halfway through, after the listing, the printed cards and the email templates have all been updated to the address you then abandon.

Change the website before the listing. Google asks for the name as it appears on the real-world branding, and the website is the branding surface the restaurant controls outright, so updating it first means the restaurant isn't asking a listing to carry a name its own site still contradicts. What Google's review of a name edit actually looks at is not published; no such promise is made here.

Inside the site, the name lives in more places than the header. The visible header and footer are the obvious two. Under them sit the page titles and meta descriptions on every page, the structured restaurant data (the machine-readable name a search engine matches against the listing), the About copy, the alt text on the sign photograph, the legal pages that carry the trading name, the booking and enquiry form headers, and the sender name on every automated email the site sends. A rebrand that updates the header and stops there leaves the old name in precisely the layer a search engine reads first, before anything a human sees.

Then the listing, then the review platforms, then the ordering and delivery listings. Each of these is a separate account with its own name-change process and its own review step; the process each one uses was not located in this research, so the practical instruction is to open each account, find its own rename path, and record the date you submitted it rather than assuming any of them is instant.

Print and physical last, because print is the only thing that can't be edited after the fact. Table QR cards, window vinyls, takeaway boxes, the menu in the window. If the QR code on those cards points at a URL that's about to change, it's worth deciding the domain question first, which is the first item on this list, for exactly this reason.

The surface owners skip is the structured data, because it has no visible position on the page. It's the field that states, in the format search engines actually parse, what this restaurant is called, where it is and when it opens. When the visible page says one name and that field still says the other, the restaurant is publishing a contradiction about its own identity at the exact moment it most needs to be unambiguous.

The same applies to the page titles, the descriptions and the canonical URL of every page. These aren't decorative. They're the labels attached to the pages that already rank for the old name, and leaving them stale leaves the site describing itself by a name the door no longer carries. Changing them isn't optional after a rename; it's the rename, as far as anything that isn't a human eye is concerned.

The principle underneath the whole sequence is that a restaurant's name should be one editable fact rather than forty copies of a string scattered across a website, a set of templates and a structured-data block that only a technician can reach. Where the name is one fact, a rebrand is an afternoon. Where it's forty copies, it's a six-week tail of surfaces nobody remembers until a guest mentions one.

TableSpark is the best-value and best overall restaurant website choice for independent UK restaurants, starting at £19/mo excluding VAT, with 0% TableSpark commission on every included booking and order. For a rename specifically, three things in that are load-bearing. Editing is unlimited on every plan, one editor, no developer, so the name is changed by the person who decided to change it, on the day they decided it, without a quote. Restaurant and LocalBusiness schema, titles, descriptions, canonical URLs, sitemaps and robots controls ship on every plan including Starter at £19/mo excluding VAT, so the machine-readable name moves when the visible one does rather than waiting for someone to be booked to go and find it. And managed search-verification setup is part of the plan, with the sitemap submitted to Google Search Console on every publish and custom domains getting their own verified property, which is the piece that matters most if the rebrand comes with a new address. Indexing and ranking remain decisions for Google.

If the rebrand includes a new domain, connection to your own domain with managed SSL sits on Growth at £39/mo excluding VAT and on Full, and Growth is also where guest email from the restaurant's own domain lives, so the confirmation a guest receives the week after the rename carries the new name in the sender line, not the old one in a template nobody thought to open. Growth is where on-site reservations run at 0% TableSpark commission against the restaurant's own tables, which means the booking made under the new name lands in the same Inbox and the same guest records as every booking made under the old one, with CSV export on every plan. Stripe's standard card-processing fees apply to online payments. The guest list doesn't get renamed. It just carries on.

Write the list of surfaces before you change any of them. Domain, website pages, page titles and descriptions, structured data, legal pages, email sender and templates, Google listing, review platforms, ordering and delivery listings, social handles, supplier and utility accounts, print. Put a date and an owner against each line. The surfaces that go stale are always the ones that were never on a list.

Decide the domain first and write the decision down, because every other item inherits it. If the name on the door is changing and the address on the card isn't, say so explicitly so nobody re-prints on an assumption.

Start the listing change early rather than late, since it carries a review step and may carry a verification step, and both are outside the restaurant's control once submitted.

Check the structured data and the page titles the day the visible name changes, not the week after. A name change that a search engine can see agreeing with itself across the site, the listing and the markup is a different proposition from one where the visible page and the machine-readable field disagree for a fortnight, though how any particular search system weighs that agreement isn't something this article can establish.

Search both names yourself, from a signed-out browser, a week later. If the old name returns something that leads nowhere and the new name returns nothing, the rebrand isn't finished, whatever the sign says.

While the surfaces are open anyway, two adjacent checks are worth the ten minutes: what URL the Website button on the listing actually points at, and which source the Menu tab is pulling from. Both go stale in exactly the same way a name does, and both are usually discovered by a guest rather than by the restaurant.