| Issue | Severity | Scope | Entity Type |
|---|---|---|---|
| International locations declare addressCountry as United States | Critical | 4 isolated pages | Restaurant |
| São Paulo location uses San Salvador's street address | Critical | 1 isolated page | Restaurant |
| Cuisine property contains misspelled values | Critical | 2 isolated pages | Restaurant |
| addressLocality fields contain state abbreviations and extraneous data | Critical | 3 isolated pages | Restaurant |
| Homepage Restaurant entity uses CMS-generated name | Warning | 1 isolated page | Restaurant |
| Homepage Restaurant has empty PostalAddress | Warning | 1 isolated page | Restaurant |
| WebSite entity with same @id has conflicting properties across pages | Warning | Sitewide | WebSite |
| 79 ReserveAction entities have no @id | Warning | Location pages | ReserveAction |
| Addison location OpeningHoursSpecification missing @type | Warning | 1 isolated page | Restaurant |
| Author nodes reference @id with no corresponding entity in the graph | Warning | Blog pages (15 articles) | Article |
| addressLocality values contain typos | Warning | 2 isolated pages | Restaurant |
| Duplicate keyword in hibachi vs teppanyaki article | Notice | 1 isolated page | Article |
| servesCuisine array order inconsistent across locations | Notice | 2 isolated pages | Restaurant |
| Gift cards page datePublished set to future date | Notice | 1 isolated page | WebPage |
"addressCountry": "United States" for restaurant addresses that are physically in Brazil, El Salvador, Panama, and Aruba respectively. Any system building a geographic index — Google’s Local pack, an LLM assembling restaurant facts, or a citation aggregator — reads these four international restaurants as being located in the United States, making them invisible in their actual countries and potentially creating phantom U.S. listings.
addressCountry value in the PostalAddress object on each page. Use ISO 3166-1 alpha-2 country codes for maximum parser compatibility:
streetAddress is set to "Calle Juan Jose Cañas 77 Avenida Sur" — a Spanish-language address that belongs to the San Salvador location. Meanwhile, the addressLocality contains what appears to be the actual São Paulo address data ("Rua Amauri, 517 – Jrdim Europa"), meaning the address fields are cross-contaminated. A processor reading this entity receives two conflicting geographic signals from the same address block, making the actual location of this restaurant unresolvable.
PostalAddress to use the actual Brazilian address:
servesCuisine array contains "Japanes" (missing the trailing ‘e’), and the Burlingame location contains "HIbachi" (capital ‘I’). Schema.org servesCuisine values are matched as text strings by processors — a misspelled value is not matched to the correct cuisine category, meaning these locations could be excluded from cuisine-filtered searches or misclassified entirely.
/locations/miami-beach/: Change "Japanes" to "Japanese"/locations/burlingame/: Change "HIbachi" to "Hibachi"addressLocality values that merge city and state data into a single field. A parser encountering "Dallas TX" as a locality cannot split it reliably and may treat the entire string as the city name, failing to match it against geographic databases. The Addison location further contradicts itself — the entity name says “Addison” while the locality says “Dallas TX.”
addressRegion is present as a separate property on each page.
Restaurant entity with "name": "Home - Benihana". The “Home -” prefix is a CMS page-title artifact leaking into the schema. Any system using this entity to identify the brand — including Knowledge Panel construction and LLM training corpora — encounters a restaurant whose name starts with “Home,” which is neither the legal entity name nor how customers refer to the brand.
name to:
Restaurant entity includes an address block containing only "addressCountry": "US" — no street address, city, state, or postal code. Combined with a missing @id, no geo, and no url, this Restaurant entity is essentially a shell with no verifiable identity. It creates a second, competing Restaurant entity alongside the Organization node that already represents the brand.
@id. If the homepage Restaurant is intended as a brand-level entity, consider changing its @type to FoodEstablishment with appropriate brand-level properties.
WebSite entity using @id: "https://www.benihana.com/#website" appears in two configurations across the site. On 80 location pages, it includes a publisher reference. On the homepage, it additionally includes a potentialAction with SearchAction. On 10 page-sitemap pages, it omits the publisher entirely. When a system aggregates entity data using @id as the reconciliation key, encountering different property sets forces a merge decision — the system cannot determine which version is authoritative.WebSite entity is identical on every page. The most complete version (with both publisher and potentialAction: SearchAction) should be used everywhere. This is typically controlled by the SEO plugin’s global schema settings (e.g., Yoast or Rank Math).
ReserveAction entity inside the @graph, but none of the 79 instances declare an @id. Without an identifier, these action entities cannot be referenced by other nodes in the graph and exist as orphaned blocks. The Restaurant entity on each page cannot formally declare that it offers this reservation action — the relationship is implied by proximity within the graph rather than stated through an explicit reference.@id values to each ReserveAction and reference them from the Restaurant entity:
openingHoursSpecification array contains seven day-of-week entries, but none declare "@type": "OpeningHoursSpecification". Without the type declaration, a strict JSON-LD parser treats these as untyped objects rather than structured Schema.org entities, risking the hours data being ignored entirely.
"@type": "OpeningHoursSpecification" to each entry. Compare against other location pages (e.g., Woodlands, Wheeling) where this is declared correctly:
author with an @id reference (e.g., "@id": ".../#author") and "name": "Fanatic", but none of these author nodes declare a @type. The referenced @id does not resolve to any standalone entity in the graph. A processor following the reference finds nothing, leaving the author identity unresolvable. Two other articles properly use "@type": "Organization", "name": "Benihana Editorial Team", creating an additional inconsistency: 15 articles credit an untyped “Fanatic” while 2 credit a typed Organization.
"@type": "Organization", "name": "Benihana" referencing the existing @id: "https://www.benihana.com/#organization" — and apply it consistently across all articles. If “Fanatic” is a real person, declare them as "@type": "Person" with proper identifying properties.
"Coral Spring" (missing the trailing ‘s’), and the North Little Rock location uses "N Little Rock" (abbreviated). These values must match the official city names used by USPS and Google Maps for NAP consistency. An aggregator comparing this data against directory listings would flag a mismatch, potentially creating duplicate or orphaned citations.
keywords property on /blog/difference-between-hibachi-and-teppanyaki/ is set to "teppanyaki, hibachi, teppanyaki" — the keyword “teppanyaki” appears twice. While unlikely to cause a parsing failure, it indicates the keywords were set manually without deduplication.
["Japanese", "Hibachi", "Teppanyaki"], but the Lombard and Cupertino locations use ["Japanese", "Teppanyaki", "Hibachi"] — swapping the order of the second and third items. While array order is not semantically significant per Schema.org, inconsistency across identical entity types suggests a data entry variation rather than intentional distinction.["Japanese", "Hibachi", "Teppanyaki"] (or ["Japanese", "Hibachi", "Teppanyaki", "Sushi"] where sushi is served).
"datePublished": "2026-01-01T00:00:09-04:00" and an identical dateModified. This date was originally set as a future scheduling artifact. The identical published and modified timestamps suggest the page was auto-scheduled and never manually updated after publication.
datePublished to reflect the actual content creation date and set dateModified to the most recent edit. The CMS may need a manual override to prevent scheduling dates from propagating into schema.
"addressCountry": "United States" would likely be filtered out of local results in their actual countries, or worse, create phantom listings in U.S. search. The São Paulo location presents an especially difficult case: its street address belongs to San Salvador while its locality field contains what should be the street address — Google’s address validation pipeline would likely discard this entity entirely. The homepage Restaurant named “Home - Benihana” with an empty address may interfere with Knowledge Panel consolidation, presenting as a distinct restaurant entity rather than a brand identifier.
@type or resolvable @id, language models cannot evaluate the authority behind Benihana’s content, reducing the E-E-A-T signal that feeds into citation confidence.
addressLocality for Addison all create matching failures when aggregators reconcile structured data against existing records. For the four international locations, declaring “United States” as the country effectively removes them from non-U.S. citation ecosystems entirely. The consistent phone format across most locations (bare digits with spaces) is parseable but deviates from the E.164 standard that maximizes automated matching.