Every Listing Data & Schema Audit check

Missing or malformed JSON-LD blocks Google's rich results pipeline entirely. When a directory listing omits a valid `<script type="application/ld+json">` block with the correct schema-org LocalBusiness or Place `@type`, Google cannot generate rich snippets — star ratings, addresses, and hours never appear in SERPs. Listings that lack structured data are effectively invisible in the competitive layer where rich results dominate click-through rates. A JSON-LD object stored in an HTML `data-` attribute rather than the script's text content is the canonical hallucination failure for AI-generated code: it compiles and renders fine, but search engine parsers skip it completely.

Why this severity: Critical because misconfigured or absent JSON-LD eliminates the directory's structured-data eligibility entirely, directly suppressing rich-result visibility for every affected listing.

Google's Rich Results Test rejects schema-org LocalBusiness markup that omits required fields, stripping star ratings and address panels from search results. Beyond SEO, empty or placeholder fields in `name`, `description`, `url`, or `address` degrade the directory's data integrity: aggregators and AI crawlers that consume your structured data surface incomplete records downstream. A listing that renders `"telephone": ""` or `"description": "TBD"` in its JSON-LD signals untrustworthiness to both search engines and users who encounter the raw data via the schema-org PostalAddress or GeoCoordinates properties.

Why this severity: Critical because incomplete required fields cause Google to reject the structured data block entirely, making the listing ineligible for all rich result types regardless of other schema quality.

Base64-encoded images in JSON-LD or direct-to-server uploads bloat HTML payloads by 30-40%, blow up your origin bandwidth bill, and destroy Core Web Vitals. LCP spikes past 4 seconds on mobile, browsers cannot cache per-image, and you lose responsive format negotiation (WebP, AVIF) that CDNs handle automatically. Google downranks slow pages, paid traffic converts worse, and every listing view costs you compute you should not be paying for.

Why this severity: Critical because origin bandwidth costs and LCP regression directly threaten directory economics and search rankings.

Uncompressed images are the single most common cause of poor Core Web Vitals scores on directory sites. A listing page that loads 10 unresized user-uploaded photos — each 3–5 MB at 4000px width — produces a Largest Contentful Paint well above Google's 4-second failure threshold, directly lowering the page's performance score and search ranking. iso-25010:2011 performance-efficiency treats resource utilization as a quality attribute: serving a 4.5 MB JPEG when a 180 KB WebP would be equivalent is a measurable resource waste paid by every visitor. Mobile users on constrained bandwidth experience this as a broken product.

Why this severity: High because oversized images measurably degrade Core Web Vitals, reducing search ranking and user retention across every listing page that displays unconstrained uploads.

A `dateModified` field populated only at creation time and never updated tells Google and AI crawlers that your listings are perpetually fresh — regardless of whether the underlying data is years stale. The schema-org `dateModified` property is used by search engines to prioritize recrawl frequency and by users to assess trustworthiness. Directories with static creation-time timestamps signal data decay: a business that closed 18 months ago still appears current. When users or LLMs consume your structured data and discover the timestamps are lies, the directory's authority collapses. Data freshness is a core data-integrity guarantee for any directory product.

Why this severity: High because a static or submitter-controlled timestamp deceives search engine recrawl heuristics and erodes user trust when listings display outdated information without any staleness signal.

A JSON-LD `aggregateRating` block that shows 4.5 stars while the page displays 4.3 stars is an active schema-org policy violation — Google's Rich Results guidelines prohibit structured data that misrepresents visible content. Discovery of the discrepancy triggers manual review and can result in a site-wide rich-result penalty. Beyond compliance, rating mismatch is a data-integrity failure: users who click a listing based on an inflated SERP star count and see a lower on-page rating experience an immediate trust collapse. The `ratingValue` and `reviewCount` in schema-org AggregateRating must be computed from the same database query that drives the visible UI.

Why this severity: High because mismatched structured-data ratings violate Google's explicit rich-results content policies, risking manual review penalties that suppress all rich results site-wide.

Incomplete `openingHoursSpecification` in structured data forces users to contact the business or visit in person to confirm hours — and misleads them when the schema implies all unlisted days are open by omission. Schema-org `OpeningHoursSpecification` requires explicit entries for every day of the week, including closures; a 5-day entry covering Monday–Friday leaves Saturday and Sunday in an undefined state that search engines may interpret as open. Users who show up based on incorrect Google knowledge panel hours generate negative reviews. For directories competing on data quality, missing hours degrade the product's core value proposition of replacing a phone call.

Why this severity: Low because incomplete hours reduce listing usefulness and search-panel accuracy but do not cause data corruption or security exposure; the failure is cosmetic and informational.

Storing a field users submitted but never rendering it silently drops the value they trusted you to display. Phone numbers missing from listing pages cost the business real leads; missing hours send customers to closed locations; missing addresses break local SEO signals and schema.org LocalBusiness structured data. Users who submitted via a suggest-an-edit form conclude the system is broken and stop contributing. Directory trust collapses quickly when visible data does not match what submitters remember providing.

Why this severity: High because dropped fields degrade listing quality, undermine user contributions, and weaken local SEO extraction.

Rendering a literal `undefined` or an empty `<p>` tag in place of a missing field makes the listing look broken and signals to users that the directory does not maintain its data. Empty gaps collapse layout, CLS scores rise, and users lose confidence that any field on the page is reliable. An explicit `Not provided` with a `Suggest an edit` call-to-action converts the absence into a contribution opportunity, which is how crowd-sourced directories keep fields populated over time.

Why this severity: High because broken UI and visible `undefined` strings erode trust on the canonical listing view users land on from search.

A directory populated with one-word or blank descriptions is functionally indistinguishable from spam. Google treats thin content as low-quality and suppresses the entire directory in search results, not just the bad listings. Users who click through to a listing with no real description bounce in under five seconds, hurting engagement metrics that feed back into ranking. Competitors with enforced minimums outrank you for the same keyword terms because their pages carry enough tokens for semantic relevance.

Why this severity: High because thin descriptions drag down site-wide SEO and let spam submissions pass through as legitimate listings.

Free-text categories produce `Restaurant`, `restaurant`, `Restaraunt`, and `Food` as four distinct buckets for the same concept. Your browse pages fragment, faceted filters break, sitemaps balloon with near-duplicate URLs that Google treats as keyword cannibalization, and analytics reports become impossible to trust. Once inconsistent data lands in the database, deduplication is a manual SQL cleanup job that costs far more than enforcing a controlled vocabulary at submission time. Schema.org `Category` emitters also require stable enum values.

Why this severity: High because free-text taxonomies fragment browse pages, break filters, and create SEO cannibalization that worsens with scale.

WCAG 2.2 Success Criterion 1.1.1 requires all non-text content to have a text alternative — a failing grade on this check means your directory is inaccessible to blind users relying on screen readers. Section 508 (2018 Refresh) §502.3.3 extends this requirement to federally procured software. Beyond compliance, empty or generic alt text like `alt="image"` degrades image search indexing: Google uses alt text as primary signal for image SEO, and directories with poorly alt-tagged listing photos lose discoverability in Google Images where visual search drives significant business referral traffic.

Why this severity: High because missing alt text is a WCAG 2.2 SC 1.1.1 failure that makes listing images invisible to screen readers, creating an accessibility barrier for blind users on every affected page.

Raw markdown or HTML leaking into rendered descriptions is a cross-cutting failure: WCAG 2.2 SC 1.3.1 (Info and Relationships) requires that semantic structure conveyed through presentation be programmatically determinable, and an `<img>` tag or `**bold**` shown as literal characters is unreadable by screen readers. Beyond accessibility, unrendered markup is a OWASP A03 injection surface — if user-supplied HTML is echoed without sanitization, even a markdown renderer can be weaponized via unsanitized `<script>` tags or event-handler attributes. Directories that accept owner-submitted descriptions and pass them directly to `innerHTML` without sanitization are one malicious description away from stored XSS affecting all visitors to that listing page.

Why this severity: Low for raw-markup display because the failure is a rendering bug, not an injection vulnerability — but severity escalates to high if the description is rendered via unsanitized `dangerouslySetInnerHTML`.

Comma-delimited strings cannot be indexed for faceted search, cannot be filtered in SQL without `LIKE '%value%'` scans, and produce false matches (`Parking` matches `No Parking`). Consumer APIs that expect arrays get strings and either crash or display literal `WiFi, Parking, Outdoor Seating` as a single tag. Migrating later requires a string-split backfill that is brittle when values themselves contain commas, and every downstream integration that already parsed the string must be updated simultaneously.

Why this severity: Low because the data is recoverable and rarely user-facing in raw form, but it blocks filtering and structured data generation.

Images without explicit `width` and `height` attributes cause Cumulative Layout Shift (CLS) — the browser reserves no space until the image loads, then reflows all surrounding content. Google's Core Web Vitals threshold for CLS is 0.1; a directory listing page with 8 unsized images can easily exceed 0.5, dropping the page into the 'Poor' range and triggering a search ranking penalty. iso-25010:2011 performance-efficiency classifies layout stability as a resource utilization quality attribute. Beyond SEO, layout shift causes users to misclick adjacent links, a user-experience failure that increases bounce rate on listing pages where conversion depends on clicking through to the business.

Why this severity: Medium because CLS from missing dimensions measurably degrades Core Web Vitals scores and search ranking, but the failure does not expose data or create security risk.

Returning a 404 for a listing that existed and was indexed tells Google the URL is permanently gone with no context, which kills any inbound links and external citations built up over the listing's lifetime. Users who clicked a remembered link or a review site referral get a generic not-found page and assume the entire directory is broken. A dedicated closed-listing page preserves the URL for link equity, explains what happened, and offers alternatives (nearby listings, contact the business) that keep the session alive.

Why this severity: Low because the 404 response does not corrupt data, but it wastes accumulated SEO equity and trust for closed pages.

A broken-image icon on a listing card is the visual equivalent of a 500 error — users interpret it as site neglect and scroll past the listing entirely, regardless of how good the underlying content is. Browse pages with scattered broken images look abandoned, review crawlers flag the domain for quality issues, and social previews (Open Graph, Twitter Card) fall back to site defaults instead of listing-specific imagery. A category-appropriate placeholder keeps the grid visually uniform and signals the listing is real, just not yet photographed.

Why this severity: Low because the underlying data is intact, but broken image icons make the entire browse grid look unmaintained.

Without a designated primary image in structured data, Google's image picker selects arbitrarily from all images on the page — often choosing a logo, ad, or decorative element over the listing's actual photo for knowledge panel display. Schema-org `image` on a LocalBusiness node tells Google's image indexing pipeline which photo represents the listing. Directories that omit this field see inconsistent image selection in rich results, with some listings showing irrelevant thumbnails in SERP previews. The `itemprop="image"` microdata attribute and the JSON-LD `"image"` property serve the same purpose; the check requires at least one of them for multi-image listings.

Why this severity: Low because absent image markup degrades rich-result presentation quality but does not cause data loss, security exposure, or structured-data rejection.

Stale directory listings are the primary user trust failure for directories: a restaurant that closed 18 months ago still showing 4.5 stars with no freshness signal sends users to a shuttered door. Schema-org `dateModified` enables recency scoring by search engines and AI crawlers — but only if the field reflects actual verification, not the creation date. Without automated staleness detection and owner alerts at 90 days, your directory degrades passively: every listing drifts toward inaccuracy while appearing current. Data-integrity and observability taxons both apply here — the system must monitor its own data freshness, not rely on owners to self-report changes.

Why this severity: High because undetected stale listings cause real-world user harm (visiting closed businesses, calling disconnected numbers) and erode the directory's core trust proposition over time.

Rating counts and averages that update on a nightly batch job rather than in real time allow the displayed schema-org `aggregateRating` to diverge from the database truth for hours after a review is submitted. A listing that receives 10 new 1-star reviews after a service failure continues displaying its pre-incident 4.5-star average until the batch runs — actively misleading users making decisions based on the structured data. Data-integrity is the core taxon: the JSON-LD `reviewCount` fed to Google must match the actual review count at page-render time. Delayed updates also suppress Google's trust in your rating freshness, reducing the likelihood of rich-result display.

Why this severity: High because batch-delayed rating updates allow structured data to misrepresent actual listing quality for hours, creating a data-integrity gap that Google's structured data guidelines prohibit.