ローカルSEO・GEO監査

# Local SEO and GEO Audit

## Loadout capabilities

Use <action-tag>api:tinyfish_api:fetch_urls</action-tag> to retrieve a small, explicit list of publicly reachable pages as Markdown or HTML with page metadata. Inspect the live schema, authentication, cost, and execution result first. Use public search through <action-tag>api:tinyfish_api:search</action-tag> to find the site's location pages, menus, services, and public listing candidates when site navigation is incomplete. Search is evidence, not proof of rank or listing ownership. If either Action is unavailable, use another approved public read route and label that source; never request merchant login solely to complete this audit.

For a WordPress site, use <integration-tag>api:wordpress_api</integration-tag> to identify the connected path and setup requirements for a later follow-up. Its current read Action lists published posts after the merchant configures the site's REST base URL and API credential; it does not cover pages, media, SEO-plugin settings, or writes. This audit uses the public fetch route for WordPress pages and does not execute a connected WordPress Action. If the integration is unconnected, keep the public audit running and mark the private post inventory unavailable.

## Inputs and boundaries

Ask for the public domain and target locations if missing. Optionally take business type, language, priority services or products, and the merchant's confirmed name, address, phone, hours, and booking URL. Restrict collection to public pages and a bounded initial sample: home page, up to five distinct location pages, up to five menu or service pages, `robots.txt`, sitemap, and up to five relevant public listings. State the sample and date. Never claim a complete crawl from a sample. Do not treat a PDF, social post, or search snippet as the sole source for a mutable business fact.

## Workflow

1. Identify the canonical site and each physical location. Record the exact URLs reviewed. Separate verified merchant facts from uncertain or conflicting public claims. For a service-area business, distinguish a hidden service address from a staffed storefront.
2. Fetch the sampled pages. Inspect HTTP availability, indexability signals when visible, canonical URL, title, meta description, H1, internal links, mobile-readable visible text, language, and whether core menus or services are available only as images or PDFs. Use HTML format where metadata or structured data needs inspection. Check `robots.txt` and sitemap by public fetch if present. A blocked fetch is an unknown, not a defect.
3. On each location page, check visible name, address, phone, hours, map or directions, booking/order route, service or menu distinctions, and evidence of unique local content. Compare only against public listing pages that can be matched confidently to the same branch. Flag disagreements with both sources; do not overwrite either source from a guess.
4. Inspect structured data when available. Compare LocalBusiness or subtype fields to visible facts and check duplicated or conflicting entities. Suggest schema corrections only for verified facts. Treat structured data as a machine-readable restatement, not a special GEO shortcut.
5. Assess answer readiness using actual customer questions: location, offerings, dietary or accessibility details, ordering, parking, service area, and policies as applicable. Mark missing answers separately from information that exists but is hard to extract. Do not promise AI citation or ranking outcomes. Apply current search-engine guidance when making technical claims.
6. Rank findings by customer impact, evidence strength, implementation effort, and reach across locations. A critical factual error or unusable conversion route outranks cosmetic metadata. Propose unique, helpful pages, not city-name swaps or keyword stuffing.

## WordPress implementation handoff

When the site is WordPress, identify the target page by public URL and proposed editor location. Give the site editor concrete values or checks for page title, URL slug, visible H1, body section, menu/service links, image alt text, and the SEO plugin's title, meta description, canonical, and index setting. Name the plugin only if observed or confirmed; do not assume Yoast, Rank Math, or another plugin. Treat hours, contact details, location schema, menus, and order links as merchant-confirmed data. Recommend saving a draft/preview first, then checking the rendered page and structured-data output before publication. Do not claim the WordPress posts Action can update those fields.

## Required output

Deliver three sections in this order:

1. **Evidence report:** business and location scope, sample/date, source URL for each observation, what was directly seen, what remains unknown, and any conflicting evidence. Distinguish a technical error from a recommendation.
2. **Prioritized strategy:** a ranked table with issue or opportunity, affected URL/location, why it matters, evidence, confidence, effort, and expected observable outcome. Do not assert traffic lift without first-party data.
3. **Operable actions:** for every priority, give the exact page or listing, proposed change, owner (merchant, site editor, or agent draft), required input or approval, verification step, and expected result. For a proposed edit, provide reviewable copy or structured-data field values only when the facts are verified. If a connected apply tool is later available, stop at a reviewed change set until the user authorizes that write.

End with a short next-check list: re-fetch changed pages, validate structured data against visible facts, and compare search performance only after an appropriate baseline and time window. Never call estimated third-party traffic measured merchant traffic.