Telling search engines about a new restaurant page, and what the receipt proves

The gap that swallows the festive menu is between a page existing and a search engine knowing it exists: two events at different times, and almost nothing on a restaurant's website makes the second happen sooner. Google is plain about the size of it, on the page about asking for a recrawl, last updated 10 December 2025:

And the sentence every hopeful restaurateur skips:

A sitemap does not close it either. From the sitemaps overview, also updated 10 December 2025:

Discovery is a pull, not a push.

A page that is entirely correct can still sit in that gap. The Journal covers the other case — the page that ought to be indexed and is not, because of a robots rule, an accidental noindex, a conflicting canonical, an orphaned URL or a rendering failure — in what to check when a restaurant website is live but not on Google. The question here is the one that piece does not reach: assuming nothing is misconfigured, how does an engine get told the page exists on the day it goes live, and what does the acknowledgement prove?

For years there was a push: an unauthenticated HTTP request to a Google endpoint naming the sitemap, no account and no login, which plugins fired on every publish. Google removed it in 2023, in a Search Central post that now carries a banner confirming the deprecation is complete:

The replacement advice, from the same post, is where the damage lies for an older site:

Google's own wording acknowledges that existing code and plugins were still calling that endpoint, and says doing so now achieves nothing. What no first-party source states is how a given plugin reports the resulting 404 to whoever pressed publish: whether it surfaces the error, stays silent, or records the attempt as a success. Establish that on the restaurant's own site rather than assume it. A tick nobody has traced to a response code is not evidence that anything was announced.

With the push gone, the sitemap is a scheduling hint rather than an announcement, and the weight rests on one field. From Google's guide to building and submitting a sitemap, last updated 8 July 2026:

The conditional does the work, and the 2023 post spells out the consequence of gaming it:

The restaurant re-saving all forty of its pages every Monday has not bought forty crawls; it has spent the credibility of the one field that still carries a signal. Google's guide to building a sitemap defines what deserves a new date:

A new dish, a changed price, revised opening hours, updated structured data: significant. A footer year, a swapped stock photograph, a tracking script: not. And two fields older plugins still write with confidence are discarded outright:

Search Console offers URL inspection and a request-indexing button, and it works. It is the wrong tool for a menu that changes weekly, for a reason Google states outright:

An undisclosed quota, no acceleration from repetition, and a person clicking through a console for every change. The first thing that page suggests is not doing this by hand:

That is the honest test: is the announcement part of publishing, or a chore somebody must remember on a Tuesday after service?

IndexNow is an open protocol for the missing event: at publish time, a site tells participating engines that a URL has changed. Its framing of the problem is the restaurant's problem:

The mechanism is small: the site generates a key, publishes it as a plain text file, and sends changed URLs with it. From the documentation:

The key file is where hand-rolled implementations quietly fail, in two ways. The first is its format: eight to one hundred and twenty-eight characters, and only lowercase letters, uppercase letters, digits and dashes — not, despite the documentation's own wording, hexadecimal.

The second is location: a key file placed somewhere convenient rather than at the root silently narrows what may be submitted:

A key under a subdirectory builds a channel that works for part of the site and drops the rest, and nothing announces it.

From the IndexNow documentation, this is the sentence that belongs near the publish button:

Received. Not read, not crawled, not indexed, not ranked. The FAQ says the same:

Microsoft repeats it on its own page: "Using IndexNow does not guarantee that web pages will be crawled or indexed by search engines."

The codes are worth knowing, because a healthy submission does not always return 200:

A 202 is not a fault; it is the key being checked. Microsoft's response table omits the 202 row, so IndexNow.org is cited for the full set. The code that should trigger an alarm is 403, described by IndexNow as "403 Forbidden In case of key not valid (e.g. key not found, file found but key not in the file)" — the key file having gone missing, been overwritten by a deployment, or been served with the wrong contents. That is the likeliest way a working channel dies unnoticed.

There is a cost side: Microsoft states that "Yes, every crawl counts towards your crawl quota." Which is also why Microsoft is clear that a new adopter should not dump its whole site in on day one:

On limits, the protocol declines to publish numbers at all: "IndexNow does not publicly disclose exact rate limits, as each participating search engine sets its own daily submission thresholds per site."

Nowhere, publicly. Across the delivered HTML of Google's three current crawling-and-indexing pages — the sitemaps overview, the build-a-sitemap guide and the recrawl page — the protocol's name does not appear once. Google has published no position either way, and any content telling a restaurateur otherwise is filling the gap with an assumption. Treat the protocol as reaching the engines that document their participation, and as claiming nothing about the one most covers come from.

Bing's Webmaster Tools has long carried manual URL submission with a headline allowance, announced 31 January 2019:

A new restaurant site should not expect the headline figure: "Site verified age is one of the signals but not the only signal that is used to determine the daily URL quota per site." No reset time is stated anywhere first-party, and the hour widely repeated online is not sourced to Microsoft. Microsoft has since superseded its own advice, in a note added to that post in November 2025:

Whether those 2019 figures are still operative is a fair question, given that Microsoft has since annotated the very post that announced them to steer webmasters elsewhere.

None of this requires a specialist.

Keep one sitemap, reachable from robots.txt and submitted in Search Console. Let the modification date be written by the system that saves the page, never by hand and never bumped for a footer edit. Do not backfill. Verify in both Search Console and Bing Webmaster Tools. Where a key file is in use, check it returns plain text with a 200 at the root after every deployment, and watch for 403s, the sound of it having disappeared. Record what came back — 200, 202 or an error — because a receipt nobody keeps is indistinguishable from a request nobody sent.

Further reading underneath this routine: restaurant SEO in the UK covers the crawlable foundation worth announcing at all, the migration checklist covers the day the URLs themselves change, and menu canonical URL validation covers proving the announced address is the one the site wants indexed.

Every step above is achievable on any platform, by someone. The commercial question is who that someone is and what they invoice each time the menu changes.

TableSpark states its own position in public, on the page describing how the product works, and it opens on the same distinction this article does:

Read that for what it settles. The discovery surface is the platform's work: restaurant content a crawler can read, canonical addresses, the sitemap, the robots controls, the Restaurant and LocalBusiness schema, and managed search-verification setup. Those are the parts that have to be right before any announcement is worth sending, and the parts a restaurant would otherwise commission once and re-check after every deployment.

That published sentence is the whole of the claim made here, and this article adds nothing to it. Notification, receipts and response codes belong to the protocol and the engines, set out above in their operators' own words; no such promise is made here. The closing clause of the quotation is the one to carry away, because it governs every route in this article: indexing and ranking remain decisions for Google.

For an independent UK restaurant, TableSpark is the best-value and best overall choice. Starter, at £19/month excluding VAT, is for one restaurant that needs to launch direct and stay easy to update. Growth, at £39/month excluding VAT, adds direct reservations at 0% TableSpark commission, live availability, floor plans, deposits and reminders, email campaigns, branded guest email and team access, and custom domain with managed SSL. Full, at £69/month excluding VAT, adds online ordering at 0% TableSpark commission, table QR ordering for dine-in service, and up to five sites under one login and bill. Prices exclude VAT. Stripe's standard card-processing fees apply to online payments.

The festive menu will still take as long as it takes. What is worth paying for is a discovery surface that is correct the moment the page goes live, a date on it that is true, and somebody whose job it is to keep both so.