From the Outside is a series where we take a real business website, evaluate what can be inspected from outside, and say what we found.

How we looked. Two of our own free tools plus a manual read, in a single ordinary visit. The Tracking Health Check reports which analytics and advertising tags a page references; the AI Answer Visibility Check reads the homepage and robots.txt the way an AI system would. Then we read the menu pages by hand, which is where a restaurant lives or dies online. Everything below came from files any visitor’s browser already downloads: no access, no credentials, no contact with the business, and nothing a normal page view wouldn’t do.

About the subject. A long-running independent restaurant in a Midwest metro, the kind with a real chef, a seasonal menu, and decades of regulars. Not a client, and anonymized throughout: no name, no address, no screenshots, numbers stated in ranges.

We want to be clear up front because this could otherwise read as criticism of a website that’s in most respects fine. The site looks good, the menu is current, and somebody has kept it up. The problems here are invisible from the front, which is exactly why they persist.

Two analytics properties, and no answer to which one is right

The tracking check found two different Google Analytics 4 measurement IDs on the same page.

It looks like double counting, and it isn’t

It’s tempting to call this double counting, and it usually isn’t. A measurement ID identifies a data stream, and two different IDs mean two independent destinations. Each one records the visit once, in its own property. Inflated numbers come from the same ID firing twice on a page, which is a different fault with a different fix. We’d rather say that than let you go looking for a doubling that probably isn’t there.

What it actually is: two sets of books, and no rule for which wins

Two properties set up by different people at different times will diverge, and quietly. One may define a conversion where the other defines none. One may filter the office’s own traffic while the other counts it. They start on different dates, so their histories cover different spans. Both dashboards are working correctly and they will still hand you different numbers for the same month.

That’s the real cost, and it lands at the moment somebody asks a question worth asking. Did last quarter beat the one before? Whichever dashboard is open becomes the answer, and the comparison looks entirely reasonable while resting on a foundation nobody has reconciled.

How this usually happens, and why it isn’t necessarily wrong

The common cause is ordinary: a web developer installed one, an agency installed another, and nobody removed anything. Two properties can be a legitimate arrangement. If a marketing vendor needs their own data and you’d rather not hand over admin access to yours, giving them a separate property is a reasonable way to do it.

So the question isn’t whether two is allowed. It’s whether anybody chose it, and whether the arrangement still matches who works for you now. A property installed by a vendor you parted with three years ago is still collecting, and somebody at that firm can still read your traffic. That may be perfectly fine. It’s worth it being a decision rather than an oversight.

The cost that’s real regardless: weight

Each analytics library is code the browser downloads, parses, and runs before your menu finishes rendering, and it compounds fast when tag manager containers stack up alongside it. If you genuinely need to feed two destinations, the sound way is to run both tags through a single tag manager container rather than layering separate snippets into the page. One thing to load, one place to look.

Our tool can’t tell you which ID is live, but Tag Assistant can

Our tool reads what the server sends and stops there. It can report that two measurement IDs are referenced and nothing about what happens next, since it never runs the page.

You can close most of that gap yourself in about ten minutes, with no account and nothing to buy. Google’s Tag Assistant connects to any public address and shows which tags actually fire and in what order. If you’d rather install nothing, open your browser’s developer tools, filter the Network tab for collect, and reload the page: each of those requests carries a tid parameter, which is the measurement ID doing the collecting. Two different values means both are genuinely live, and one value means the other is inert.

What stays out of reach is the part that decides whether the numbers mean anything. Whether those IDs are two separate properties or two web streams of one, which would be a messier problem. How each defines a conversion, what traffic each filters out, when each started collecting, and who holds the account. Tag Assistant shows you the tags on the page and stops at the private container detail behind them, which is exactly the right boundary to know about. It’s why the finding is “there are two, and you need to know which is authoritative,” rather than a verdict on what each is recording.

The menu is readable and says nothing

Here’s the interesting part.

The menu isn’t trapped in a PDF, and it isn’t a photograph of a printed card, which were the two failures we expected and hoped to not find. It’s real HTML text, about 1,500 words of it, with the dishes and descriptions right there in the markup. Whoever built this did the hard part correctly.

And yet the site carries no structured data at all. Not on the homepage, not on the menu pages.

The distinction matters more than it sounds. Readable text means a machine can see the words “pan-seared salmon” and a number next to them. Structured data is the labeling that says this is a restaurant, this is its menu, this is a dish, that number is its price, these are the hours, this is the cuisine. Without it, every one of those facts has to be inferred from prose, and inference is where you lose.

That’s expensive for a restaurant, specifically because restaurant questions are the kind a machine answers directly rather than by handing over ten links:

  • “What’s on the menu at ___?”
  • “Is ___ open right now?”
  • “Somewhere in ___ for a birthday dinner with a vegetarian option”

Answering those requires knowing that this page is a menu and that page lists hours. The restaurant has published all of it and left out the one layer that enhances legibility for search. It’s the difference between a menu a person has to sit and read and a menu a machine can answer questions from.

One thing to be precise about because plenty of advice on this is loose: adding menu markup will not produce a fancy menu display in Google results. Google’s restaurant carousel is limited to a small set of registered providers, and this restaurant almost certainly can’t get into it. What Google does document and use for a business like this one is LocalBusiness markup carrying menu as a link, plus servesCuisine, priceRange, and openingHoursSpecification. The fuller Menu and MenuItem vocabulary is real, and it’s worth adding, but the reason is machine comprehension broadly rather than a Google feature. We’d rather say that than sell a rich result that isn’t on offer.

Ten <h1>s and no meta description, and only one of those is worth your time

The homepage has more than ten <h1> headings, and it doesn’t have a meta description.

The heading count, and why we won’t blame it for rankings

On the headings, this is a place where standard SEO advice and Google’s stated position part company, so we’ll side with the primary source. In its SEO starter guide, Google says there’s “no magical, ideal amount of headings a given page should have,” and that while keeping them in semantic order is “fantastic for screen readers,” running them out of order doesn’t matter to Search.

So we won’t tell you ten <h1>s is costing this restaurant rankings. Google says it isn’t.

Two narrower reasons still make it worth fixing. The first is the one Google concedes in that same sentence: people using a screen reader navigate by heading, and a page where everything is top-level offers them a flat list instead of a structure. The second is that any system building an outline of the page has to guess at the subject when eleven things claim to be the subject. Google’s own guidance ends with the line we’d lead with here: “if you think it’s too much, then it probably is.” We’d recommend that the page lead with and only have a single, focused H1.

The missing meta description, which matters more to AI than to Google

This one is simpler, with one honest caveat. Without one, the sentence shown beside your listing gets generated from the page, and the result is usually adequate and occasionally strange.

Writing your own is worth the few minutes per page, but not for the reason it’s usually sold. It won’t reliably be the sentence Google shows: Portent measured Google rewriting the description on 68% of desktop results and 71% on mobile, and Ahrefs put it near 63%. Google treats your description as one candidate among several and often prefers text it pulls from the page itself.

It still earns its place. It’s what appears in the cases where Google does use it, and more to the point of this post, other systems take it at face value: link previews when somebody shares your menu, and the AI crawlers reading the served HTML. Google is the one reader that rewrites you. It just happens to be the loudest.

The ordering platform owns the customer data

This site was built on a restaurant-specific website platform, and online ordering hands off to that vendor’s own domain rather than staying on the restaurant’s.

This isn’t a fault. These platforms exist because running a restaurant is hard and building a website isn’t the job. But the trade is worth naming because it stays invisible until it matters: the customer record, the order history, and much of the measurement live in a system the restaurant rents. If they ever leave, the site stays behind and so does the data. That’s a bad thing to discover during the move rather than before it.

If you’re choosing a platform now, three questions are worth asking in writing: who owns the customer list, what leaves with you, and what happens to the domain. We built a free Proposal Red-Flag Checker for exactly that conversation.

Fix the ruler first, then move what it measures

The structured data is the bigger prize, and the analytics get fixed first anyway.

The larger commercial loss here is the visibility problem. A restaurant with a genuinely good, fully published menu is unreadable to the systems people increasingly use to choose where to eat, and that’s real demand being answered by somebody else.

But the analytics question gets settled first inside the work, and not because it’s worth more. The moment you improve visibility, you’ll want to know whether it worked, and that needs one agreed source of truth to measure against. Fix the ruler, then move the thing you’re measuring.

One question to settle before any of the page-level work. Steps three through five below are edits to pages. If a platform move is realistic in the next year or so, decide that first, since some of that work would otherwise be done twice: once on a site they’re leaving, once on the site they arrive at. The current platform may also limit how much of it is even possible.

If a move is likely, the efficient sequence is to fix the measurement now, hold the on-page work, and build the new site correctly the first time. If a move is off the table, or the restaurant needs the site performing while a replacement is built, do all of it now and accept the overlap knowingly. That’s a budget decision rather than a technical one, which is exactly why it belongs to the owner and not to whoever is doing the work.

In order:

  1. Settle which property is authoritative. Find out who owns each one and when it started. If there’s no live reason for the second, retire it and keep the one with the longer history. If there is a reason, keep both deliberately and route them through a single tag manager container. Either way, write down which one answers “how did we do last month,” and note the date, since your history will have a seam in it.
  2. Then check that it’s measuring something worth knowing. A property can be configured correctly and still count nothing that matters. Decide first what a good outcome actually is here: a reservation, a takeout order, a tap on the phone number, someone reaching the bottom of the menu. Then confirm each one is defined as a conversion and genuinely recording, and add the ones that aren’t. Skipping this is how businesses end up with tidy traffic charts that can’t answer a single question worth asking.
  3. Add LocalBusiness markup with hours, price range, cuisine, and a link to the menu, then extend to Menu and MenuItem for the dishes themselves. A developer afternoon, not a project.
  4. Review the heading structure, not just the count. Give each page one <h1> naming what that page is, then read the <h2>s and <h3>s underneath on their own and ask whether they’d form an outline somebody could follow with the body text hidden. That’s roughly what a machine builds from them.
  5. Review titles and meta descriptions together, page by page. They’re written for the same moment, and they’re the two things you control about how a page introduces itself, to search results and to anything else quoting a page it hasn’t rendered.

What we couldn’t see

The reservation flow, the third-party delivery arrangements, and what any of it costs. Inside the tag container or the ordering platform. None of the above is a judgment about the restaurant, only about the machine-readable layer around it.

We also can’t tell you what any of this is costing in lost business. Producing that figure honestly takes your average check, your margins, and how many of your tables already come from people who found you online, and none of those are visible from out here. Anyone who hands you a number without them has multiplied some assumptions together and rounded up.

So rather than offer you one, we built a Missed-Lead Calculator that runs the same arithmetic on figures you supply, and says on the page that it’s an estimate built on your inputs rather than a measurement. The number is only ever as good as what you put in, which is the point.

Want to know what a machine can read on your own site? The AI Answer Visibility Check is free and takes about a minute, with no email required. If the answer needs someone to act on it, we also do technical SEO and AI answer visibility.

Sources: Google Tag Assistant · Google on data streams and measurement IDs · Google on LocalBusiness structured data and the restaurant carousel · Google’s SEO starter guide on headings · Portent on how often Google rewrites meta descriptions · Ahrefs meta description study · Google on how search result snippets are generated · schema.org Menu vocabulary