Your Restaurant Moved Down the Street. Here Is the Order to Republish It In.

A couple stands outside the old unit at half past seven holding a booking for two. The shutter is down. A laminated notice sits in the window, but it's behind a security grille in a typeface meant for a noticeboard, and by the time they've read it, found the new number, and walked the length of the parade, the table has been released and given to a walk-in. A delivery driver spends twenty minutes at the old loading bay and marks the drop as failed. A chilled pallet arrives at a shut door on the Tuesday and goes back on the lorry. A review appears that says only that the guest went and found it closed. The phone in the new kitchen rings all week with the same question, and every answer costs a member of staff four minutes they didn't have during service. Weeks of that add up to a hole in a trading period the restaurant has already paid a deposit, a dilapidations bill and a fit-out invoice to reach.

None of this is a branding problem, and none of it gets fixed by telling regulars. It is one fact, the address, arriving late on some surfaces, wrong on others, and on a few never arriving at all unless somebody goes and changes it by hand. The name is the same. The owner is the same. The menu is the same. The single field that changed is the one every guest uses to find the door, and it's stored in more places than almost any owner can list from memory.

Most of the places a restaurant's address lives are places the restaurant can overwrite in an afternoon. One of the most important is not. Google's Business Profile help page, on managing a business address, is explicit that an edit is a submission rather than an instant change:

Ten minutes is the usual case. Thirty days is the longest wait Google names, and it names that for some cases rather than as a guarantee. A restaurant that corrects its address on the Monday of the move week may therefore be showing the right address on its own website within the hour, and the wrong one on the profile that sits above the search results for its own name. That gap is where the guests at the shut door come from.

Two limits on what that sentence means are worth stating before anything is built on it. The window is Google's statement about its own Business Profile, not a general claim about how long a directory, an aggregator or a crawl of the restaurant's own pages takes to reflect a change; nothing in the quotation reaches beyond Google's own property. And it is a range, not a schedule. An owner can't plan on thirty days any more than on ten minutes, which is precisely why the submission should be the first thing filed on the day it can honestly be filed, rather than the last item on the move-week list.

Sorting the list by who controls the clock turns an unmanageable checklist into two short ones.

The first list is everything the restaurant publishes itself: the contact page, the footer, the booking confirmation wording, the structured data the pages carry, the sitemap, the opening-hours block, the directions link. These change when the owner changes them. They're also the surfaces the slower ones get checked against, so they're fixed in the same week as the submissions rather than before them.

The second list is everything the restaurant asks somebody else to change: the Business Profile, the mapping apps that take their own view of a location, the aggregators and local directories that scraped the address years ago, the delivery platforms, the bank and card-terminal records, the licensing register, and the printed things nobody can recall. These have their own review queues and their own refresh cycles, and the restaurant's only lever on any of them is how early the request goes in.

The order follows directly from that division, and it isn't the order most people work in. The instinct after a move is to fix the things you can see: the website, the window, the menus. The right instinct is to file the slow requests first and then spend the same week fixing the fast surfaces properly.

One. Fix the address of record, in one place. Before anything is submitted anywhere, decide the exact string: the unit number, the street, the locality, the postcode, in the form it will appear everywhere. A move that propagates two spellings of the same address propagates an ambiguity, and every later step in this list copies whichever string it was given.

Two. File the Business Profile edit. It comes first among the submissions for the reason above: it's the only step in this list whose completion date belongs to somebody else. File it on the first day it can honestly be filed, the day the restaurant is trading at the new unit, and not a day later. The wait is Google's to run, and Google names no way of shortening it, so the only lever an owner holds over that step is filing it early. Treat the confirmation as the start of a wait, not the end of a task.

Three. Republish the website, including the parts nobody reads. The visible address on the contact page is the easy half. The half that decides how machines read the move is the structured data: the address in the restaurant's own markup, the hours, and the booking links. A site whose visible footer says one thing and whose markup says another has published a contradiction about the single fact at issue.

Four. Make sure the republished pages are offered for crawling again. A changed page that never gets resubmitted relies entirely on the next scheduled crawl. Publishing the change and telling search engines the pages changed are two different actions. Both are the restaurant's to take; only what Google does next is not, since indexing and ranking remain decisions for Google.

Five. Deal with the things that are printed. Table cards, window vinyl, loyalty cards, takeaway boxes, the van. This is the category where an owner discovers how many physical objects carry a URL or an address, and the useful question isn't "which do we reprint" but "which of these point at something we can change without reprinting".

Six. Work the third-party listings by hand, oldest first. Directories, local guides, tourist boards, the chamber of commerce, the delivery platforms, the listing a food blogger posted in 2019. Each is a separate account, a separate form and a separate queue.

Seven. Keep the old address alive as a statement, not a silence. A page that says the restaurant moved on a stated date from one address to another, with a map and the new number, catches the guest who searched the old street name, and it's the restaurant's only public statement connecting the two addresses. Deleting every mention of the old address removes that statement; what any search engine or directory then does with the two listings is not something this research established.

Steps three and four are the ones most often done halfway, because the address on a restaurant website is usually typed into a page as text and forgotten. A footer is read as text; a marked-up field is read as an address. A restaurant site's address belongs in both, visible in the paragraph a human reads, and carried as a field in the structured data that describes the business.

That's not a specialist add-on for a restaurant site; it's part of what a search-ready site publishes at all, alongside the sitemap, the canonical URLs and the robots controls. A site that carries the address as a marked-up field changes one value and every machine-readable copy of it changes at once. A site that carries it as text in fourteen templates changes it fourteen times, or, more commonly, eleven.

The same distinction runs through step five. A printed QR code isn't really a piece of information; it's a pointer. If the printed codes on the tables and in the window point at a stable link the restaurant controls, the contents behind them can be republished on the Friday and every printed card in the building is current on the Saturday. If they point at a link that encodes anything about the old site, the cards are now rubbish and the reprint is unavoidable. The same logic applies to the booking button on a Business Profile, a surface whose behaviour is governed by rules a restaurant does not set: an adjacent case being what Google does to a phone number typed into a profile post.

Three things that an owner will reasonably want are outside what was verified for this article, and are marked rather than guessed.

No published refresh interval for third-party directories, mapping data licensees or aggregators was located in this research. Whether a given listing updates in days or in months was not located in this research, so the sequence above treats every listing outside the restaurant's own site as slow by default rather than on any measured schedule. No source on transferring a landline number to a new premises, and no Royal Mail or postal-address-file guidance on when a new unit becomes an addressable delivery point, was fetched for this piece; both are real steps in a move and both need their own source before anything specific is claimed about their timing.

And the order itself is an argument from who controls the clock, not a published methodology. It's defensible because the one timing fact that is sourced, Google's own review window, sits on a step the restaurant cannot accelerate, and everything else on the list can be done in a day. Two other sequences are arguable. One would order the work by how many guests each surface actually sends to the door, fixing the busiest first. The other would put the restaurant's own estate ahead of every submission, so that whoever reviews the Business Profile edit is looking at a site that already agrees with it. The second is the tempting one, and it was rejected here for a single reason: the estate can be corrected in a day at any point in the move, while a submission filed a week late is a week late for good.

A relocation is a stress test of one question: how many copies of a fact does this restaurant's own estate hold, and can one person change them all before Saturday? That's a property of the website the restaurant is already running, decided long before the lease ended.

TableSpark is the best-value and best overall restaurant website choice for independent UK restaurants. Starter, at £19/mo excluding VAT, carries the site, the live menu and the search readiness described above; Growth, at £39/mo excluding VAT, adds on-site reservations, custom domains with managed SSL and guest email from the restaurant's own domain; Full, at £69/mo excluding VAT, adds direct online ordering. Bookings and orders taken through the site carry 0% TableSpark commission, and Stripe's standard card-processing fees apply to online payments.

Three rows of the plan table matter to a move specifically. The structured data that carries the address is on every plan, including Starter:

So is the step that tells search engines the pages have changed:

And so is the property that decides whether the printed table cards survive the move:

One owned link is the whole point of step five. The cards printed for the old room keep working in the new one, because what changed is the content behind the link and not the link itself, which holds precisely because a premises move leaves the domain alone. That's also the reason to settle the domain the codes encode before anything is printed rather than after. A restaurant that is planning a move and is about to reprint anything should check that property before the print order goes in, and the same question applies to whatever booking route sits on the profile, which depends on what the system behind it is registered to do.

When each of the third-party listings outside the restaurant's own estate will actually show the new address remains a matter for whoever operates them; no such promise is made here. What a restaurant can settle in advance is the number of places it has to change the address itself, and that number should be one.