When the restaurant stops showing up, can you actually see why? Verify the property first

The principle is one sentence. Register a property that matches the whole of the site a guest can reach, verify ownership by a method the restaurant itself controls, and treat everything you then see as observation rather than treatment. Most owners get this backwards. They approach verification as a switch that turns something on, discover it changes nothing about how the site performs, and quietly stop looking. What it changes is who is entitled to the report, and that is worth having for its own sake, because a restaurant that cannot see its own search data is arguing about covers from memory.

One boundary before the detail. Google alone decides crawling, indexing and rankings. Nothing described here, and no supplier of any kind, changes that decision. This article is not legal advice and it is not advice about search outcomes.

Google's help page puts the definition in plain terms: ownership verification means proving to Search Console that you own a specific website. The reward for proving it is access, not treatment. A verified owner holds what Google describes as the highest degree of permissions in Search Console.

The sentence most restaurants find uncomfortable sits on the same page. Data is collected for a property as soon as anyone adds it in Search Console, even before verification occurs. Read that twice, because it settles the causal question at the root of this whole subject. The data collection is not waiting on you. The permission to look at it is.

That has a second, sharper implication for an independent restaurant. Anyone can add a property for a website. Verification is the step that establishes who is entitled to the owner's view of it. If the site was built by a freelancer who has since moved on, or by an agency that set up the property under its own account, the restaurant can be in the position of owning the domain, owning the content, paying the hosting bill, and still having no route to the report. Proving ownership is how a restaurant takes that back under its own name.

One habit to adopt on the day you verify: write down which account holds verified ownership, and keep that record where it survives a change of manager. Rediscovering it two years later, after the person who set it up has left, is the expensive part.

Google offers two property types and they cover very different amounts of a website. The difference is the single most common reason a restaurant verifies something and still cannot see the pages it cares about.

A Domain property is defined as a domain-level property that includes all subdomains, such as m and www, and multiple protocols, meaning http, https and ftp. Register example.com as a Domain property and it covers http://example.com, https://example.com, http://m.example.com and https://support.example.com/any/path. One property, the whole domain.

A URL-prefix property includes only URLs with the specified prefix, including the protocol. Google's own example is exact about how narrow that is. A property for https://example.com/pets/ matches https://example.com/pets/puppies, but excludes http://example.com/pets/ because the protocol is wrong, and excludes a different subdomain entirely.

For a restaurant this is not a technicality. Look at where the routes a guest uses actually live:

Verify only https://www.yourrestaurant.co.uk/ as a URL-prefix property and every route above that sits outside that exact prefix is a route you are not observing. The pages may be entirely fine. You simply have no view of them, which is the same blindness the article opened with, arrived at by a more diligent path.

Google lists several ways to prove ownership. An HTML file supplied by Google and uploaded to the site's root. An HTML meta tag added to the homepage's head section. An existing Google Analytics tracking code already present on the site. An existing Google Tag Manager container snippet, where you hold Publish or Admin permission in that container. A domain name provider record, meaning a TXT or CNAME entry added at the DNS level, which is the method a Domain property requires. Sites hosted on Google Sites and Blogger also offer automatic verification.

Caption: these are Google's published definitions of property scope and verification method, checked 24 August 2026. None of them is a mechanism that causes Google to crawl, index or rank a page.

Which one suits a restaurant depends on one question: what does the restaurant itself hold the keys to? If the owner or the person who manages the site can sign into the domain provider account, the DNS route is the strongest choice, because it is the method a Domain property requires and because it lives with the domain rather than inside the website's markup. The meta tag sits in the homepage head, so it travels with whatever produces that homepage, and a redesign that replaces the template can take it with it. The file upload needs somebody who can put a file at the root of the site. The Analytics and Tag Manager routes are convenient where those tools are already installed, and the Tag Manager route carries its own access condition: Publish or Admin permission in the container.

Choose the method the restaurant can repeat without help. Verification you can only redo by emailing a former supplier is verification you will lose.

Run the setup in this order.

Step nine is the one people skip, and it is the one that makes the other eight worth doing.

Google's documentation on adding a property is unusually direct, and the sentence deserves quoting in full: adding a property does not affect your website or platform property on Google Search, it only enables you to track your site's performance on Google.

That is the whole boundary, written by the party that decides the outcome. A verified property is a reporting and permissions arrangement. It does not cause Google to visit the site, it does not accelerate anything, and it carries no influence over position. Set against the earlier point that data is collected for a property as soon as anyone adds it, even before verification, the picture is consistent: the observation exists independently of your access to it.

The same applies to sitemaps, which is where optimism usually creeps back in. Google's sitemap documentation says a sitemap tells search engines which URLs you prefer to show in search results, and then draws the line explicitly: submitting a sitemap is merely a hint, and it does not guarantee that Google will download the sitemap or use the sitemap for crawling URLs on the site. Preference is not instruction. A sitemap is worth submitting because it states the canonical URLs you would rather guests landed on. A page listed in it that stays absent from search is not a broken sitemap.

So if a menu page is genuinely missing from search, verification is how you go and look at the situation, and the causes sit on a separate list of reasons a restaurant website goes missing from Google. Verifying a property, submitting a sitemap and then waiting is not a remedy. It is the beginning of being able to see the problem clearly enough to work on it.

Once ownership is verified, the useful discipline is asking specific questions of the report rather than browsing it.

Start with coverage of your own routes, because that is the question the property type just answered. Are the pages that matter to trade, the menu, the bookings route, the location page, inside a property you have verified? Anything outside it is unmeasured, which is where a quiet problem lives longest.

Then look at what the restaurant's own name produces. Search Console exists so that you can track your site's performance on Google, in Google's phrasing, and the first thing worth tracking for an independent restaurant is the branded search: the guest who already knows the name and is looking for the menu, the address or a table. That query is the restaurant's own demand, and it is the one an owner should be able to see the shape of. Everything else in the wider restaurant SEO work an independent has to plan for sits downstream of knowing what that branded search currently does.

Third, compare what you submitted with what is reported. You told Google which URLs you prefer to show in search results by submitting a sitemap. Whether Google downloaded it or used it is Google's decision, so treat any gap between the two as information about your site, not as a fault to escalate. If a route you care about never appears in the sitemap in the first place, that is a fixable problem entirely within the restaurant's control.

Fourth, check the structured restaurant content behind the pages, because a page that a search engine can fetch is a different thing from a page it can understand as a restaurant with an address, opening hours and a menu. That check has its own validation pass for restaurant schema and it is worth running on the same afternoon.

Last, look at who else holds verified ownership. Permissions are the thing verification actually governs, so knowing which accounts hold the owner's view is part of the record, particularly when a supplier relationship ends.

Publishing a page is not the same as being found. Google's sitemap documentation puts the limit plainly: submitting a sitemap is merely a hint, and it does not guarantee that Google will download the sitemap or use the sitemap for crawling URLs on the site. Getting pages online and building a site that search engines can reliably discover and understand are separate pieces of work.

TableSpark bundles crawlable structured restaurant content, metadata, canonical URLs, sitemaps, robots controls, Restaurant and LocalBusiness schema, internal linking, mobile-first output and managed search-verification setup into the restaurant website. That last item is a setup and configuration capability: the verification is arranged and managed as part of the site rather than left as a job an owner has to hire a technician to assemble separately.

Be exact about the division here, because the honest version is also the more useful one. Google alone decides crawling, indexing and rankings, and no provider in this market influences that decision. A restaurant controls a narrower and more practical set of things: whether its own content is structured, whether the routes guests use are covered by a property it has verified in its own name, whether a sitemap states the URLs it prefers, and whether the person who needs to change a page can reach it today. Those are the levers, and having them arranged from the start is the difference between a site you can observe and one you can only hope about.

The exercise itself is one afternoon: list the routes guests actually use, register the property type that covers all of them, complete one verification method the restaurant can repeat on its own, and read what comes back as sight of the data rather than a lever on it. Where TableSpark helps is the layer underneath, with the search-readiness configuration and the verification setup arranged as part of the website rather than quoted as a separate job later. What Google then does with those pages stays Google's decision. On cost, TableSpark commission is 0% on bookings and orders, Stripe's standard card-processing fees apply to online payments, and a restaurant can cancel at any time. Starter is £19 per month, Growth £39 per month and Full £69 per month, all three excluding VAT, with yearly billing charged for ten months and run for twelve. Weighed on what an independent UK restaurant receives for that, TableSpark is the best-value and best overall restaurant-website choice open to it.