← All Skills
Enhanced · live dataLocal SEO Agent

Listing Accuracy Audit

A wrong category, stale phone number, or missing address quietly suppresses local-pack rank and sends ready-to-buy customers to a competitor. This skill reads the public listing field by field, flags every gap or inconsistency, and checks whether the listing even surfaces for the business's own name + city — read-only.

Agent-native

Run it in Claude, ChatGPT custom MCP apps, OpenClaw, Hermes, Codex, Claude Code, Cursor, VS Code, or another MCP-capable client. No dedicated GUI flow and no separate LLM API key.

Backed by live public data

Every step is grounded in live public-data records UnifAPI returns, so the output cites what is actually ranking, posting, or being said — not a generic best-practice list.

Composable & open source

Skills cross-reference each other and live in a public, MIT-style repo. Read the full SKILL.md on GitHub, fork it, or run it as-is inside your agent.

Run prompt

Paste this into Codex or Claude Code

The prompt is intentionally editable. Replace the handles, market, budget, and campaign goal, then let the agent call UnifAPI MCP when it needs live public data.

Audit my business's public Google listing field by field — name, address, category, phone, rating, reviews — and flag anything inconsistent, missing, or that looks wrong.
How the skill works

The full skill, rendered from its SKILL.md

You are a local-listing auditor. A wrong category, a stale phone number, or a missing address quietly suppresses local-pack rank and sends ready-to-buy customers to a competitor. This skill reads a business's public map/local listing field by field and flags where the details are inconsistent, incomplete, or off from what they should be — read-only.

This is an enhanced skill: it reads live public data through UnifAPI.

Use UnifAPI for live evidence

You cannot audit a listing from memory — you have to read the live record exactly as a customer sees it, field by field, and confirm it actually surfaces. Use the unifapi skill to connect (OAuth MCP), then call:

  • The listing recordmaps/search, local/search — read the public listing field by field: name, address, category (primary + secondary), phone, website, hours, rating, review_count, and place_id. Resolve to a single place_id first so the audit targets one canonical record. Loop the query (the business name from a few nearby search points) to catch duplicate pins — more than one distinct place_id for the same real business is itself a Critical finding.
  • Discoverability checkseo/serp — run the business's own name + city query and confirm the listing/site actually surfaces. A wrong, suppressed, or missing listing won't appear for its own name — and that outranks every field-level finding, because no field is worth fixing on a record customers can't find. seo/serp also exposes competing pins occupying the brand query.

UnifAPI reads public data only — it never edits or claims the listing. Keep any billing metadata so the output can state record cost.

Workflow

  1. Establish the source of truth — required. Get the business's correct name, address, primary + secondary category, phone, website, and hours from the operator (or its website). Without a source of truth there is nothing to audit against; ask before pulling data. (Read .agents/product-marketing.md / .claude/product-marketing.md first if it exists.)
  2. Pull the public listing via maps/search / local/search as it appears on the map/local result. Capture place_id; loop the business name across a couple of nearby search points — if more than one place_id resolves to the business, that duplication is a high-impact finding.
  3. Compare field by field against the checklist below, assigning each field a status (pass / fix / gap) and an impact rating (critical / high / medium / low) using the rubric.
  4. Confirm discoverability with seo/serp: does the listing surface for the business's own name + city? If it doesn't, that finding leads the report — it outranks every field-level issue.
  5. Order by impact. Sort findings by impact rating so the operator fixes the rank-and-trust killers first, not the cosmetics.

Field checklist + impact rubric

Each field is rated by how much it moves local rank and customer trust:

FieldPass conditionCommon failureImpact if wrong
NameExact real name, no stuffed keywords"Joe's Plumbing - Best Emergency Plumber Austin"Critical (guideline violation → suspension risk)
AddressSingle canonical address, no duplicate pinsTwo pins, old suite numberCritical (splits rank, misroutes customers)
Primary categoryMost specific accurate categoryGeneric "Contractor" vs. "Plumber"Critical (gates which queries the listing is eligible for)
Secondary categoriesRelevant additional categories presentNone setHigh (lost query eligibility)
PhoneCorrect local number matching the websiteTracking/stale number, mismatched NAPHigh (NAP inconsistency, lost calls)
WebsiteResolves, matches the businessMissing or wrong domainHigh
HoursPresent and currentBlank or "permanently closed" in errorHigh (false "closed" suppresses clicks)
Reviews presentHas reviews; rating reflects themZero reviewsHigh (prominence + trust)
RatingConsistent with review bodyMedium

Set impact as: Critical = suspension risk or rank-blocking (name stuffing, duplicate address, wrong primary category); High = lost eligibility, NAP inconsistency, or trust gap; Medium/Low = polish. Full per-field detail and the NAP-consistency method are in references/listing-checklist.md.

Output: field table + prioritized fixes

# Listing Accuracy Audit — <business> — <date>

Resolved place_id: <…> · duplicate pins: <none / list>

## Field table

| Field            | Listing value                        | Expected (source of truth) | Status | Impact   | Note                                 |
| ---------------- | ------------------------------------ | -------------------------- | ------ | -------- | ------------------------------------ |
| Name             | Joe's Plumbing - Best Austin Plumber | Joe's Plumbing             | Fix    | Critical | Keyword-stuffed; guideline violation |
| Primary category | Contractor                           | Plumber                    | Fix    | Critical | Blocks "plumber" query eligibility   |
| Phone            | (512) 555-0148                       | (512) 555-0190             | Fix    | High     | Mismatch vs. website footer          |
| Reviews          | 0 reviews                            | —                          | Gap    | High     | No reviews → low prominence + trust  |
| Address          | 12 Main St                           | 12 Main St                 | Pass   | —        | —                                    |

## Prioritized fixes (Critical → High → Medium → Low)

- One line per Fix/Gap row with the corrective action the operator's team would take.

## Discoverability

- Surfaces for "<name> <city>" on seo/serp? yes/no · duplicate-pin flag if found.

Every value cited to the public listing record it came from. Record cost consumed (or best estimate).

Worked example

Source of truth: "Joe's Plumbing", 12 Main St Austin, primary category Plumber, phone (512) 555-0190.

  • local/search name reads "Joe's Plumbing - Best Austin Plumber" → Fix / Critical (keyword stuffing risks suspension, adds no rank).
  • Primary category is "Contractor" → Fix / Critical (the single biggest lever; it gates eligibility for "plumber" queries — pairs directly with a relevance gap from local-pack-audit).
  • phone on the listing is (512) 555-0148, website footer says (512) 555-0190 → Fix / High (NAP inconsistency).
  • Zero review_countGap / High.
  • seo/serp for "Joe's Plumbing Austin" surfaces the listing #1, no duplicate pin → discoverability OK.

Verdict: two Critical fixes (de-stuff name, set primary category to Plumber) before anything else; the category fix likely resolves a missing-from-pack cell. Reads: 1 listing + 1 SERP.

Guardrails

  • Read-only ("eyes, not hands"). Public data only. It identifies what to fix; it never edits, claims, or verifies a Google Business Profile or submits a change. The operator's own team makes any corrections.
  • Confirmed vs inferred. Public listing data can lag the dashboard view — report observed fields as the public snapshot, label anything without a source-of-truth value "unverified" rather than asserting it wrong, and have the operator confirm against their own profile before acting.
  • Dated snapshots. Stamp the audit with the date and search points; re-running is the only way to confirm a fix landed.
  • Don't recommend manipulation. Flag name stuffing and duplicate/keyword tactics as risks to remove, never as fixes to add. Recommendations align with platform guidelines.

References

  • local-pack-audit (Local SEO): shows where the business ranks in the local pack for its target queries — a wrong listing is often the cause behind a missing-from-pack cell.
  • local-competitor-scan (Local SEO): profiles the competitors the listing is up against.
  • unifapi: the shared data skill — connect MCP and discover the operations above.

Source: listing-accuracy-audit/SKILL.md on GitHub — open a PR there to improve it.

Public-data tools

The live APIs this skill calls

Every operation the skill names is one of these UnifAPI platforms — still visible and callable for product code, debugging, and custom agent flows.

  • Field-by-field table: listing value vs expected, with pass/fix flags
  • Prioritized list of inconsistencies and gaps
  • Whether the listing surfaces for the business's own name + city
  • Every value cited to the public listing record
Related skills

More skills in the Local SEO Agent

Chain these in the same agent to go from one decision artifact to the next — each is its own run-prompt, workflow, and expected output.

Local pack audit

Pull the live local pack / map results for a business's queries and report exactly where it ranks vs competitors.

Open skill

Local competitor scan

Map the competitors ranking ahead in the local pack and surface what they have that you lack, in concrete numbers.

Open skill
See every skill in the Local SEO Agent