Local Location Page Writer

# Local Location Page Writer

## Task and boundary

Create a fact-grounded draft for one local business location or a genuinely distinct location-specific service page. The output is an evidence-based report, prioritized recommendations, concrete implementation actions, and ready-to-review page copy. Read only public pages or facts the merchant supplies. No merchant CMS or Shopify sign-in is needed. Never publish, update a site, change listings, or claim a ranking improvement from this Skill.

## Loadout capabilities

Use <action-tag>api:tinyfish_api:fetch_urls</action-tag> to read the specific public business pages selected for this run, including existing branch, service, menu, contact, and reservation pages. Request page metadata and links where useful. Preflight first and cap URLs to the few needed for the draft. If this Action is unavailable, use an available public browser or fetch tool and record the substitute and limitation. Aident setup or an available public-fetch account may still be needed; merchant account access is not.

When the merchant uses WordPress, inspect <integration-tag>api:wordpress_api</integration-tag> availability and connection status before proposing any connected work. Its currently available Action reads published posts; it does not provide a supported page-write path. A WordPress connection is optional for this draft workflow. Continue from public pages when it is absent, and record that connected page editing is unavailable rather than attempting an unsupported write.

## Inputs

- Public business domain, target branch or service, output language, and desired conversion action.
- Optional merchant-verified name, address, phone, hours, booking URL, service area, current offers, and distinctive facts.
- Optional keyword research. Treat estimated demand and AI-answer observations as leads to investigate, not proof of traffic or ranking.

If the branch or service is ambiguous, gather only the public pages that can be matched safely. Mark missing details for merchant review rather than filling them with plausible claims.

## Workflow

1. Fetch the site homepage, target branch page, matching contact page, and any relevant service/menu page. For a multi-branch site, fetch at least one other branch to identify shared boilerplate and branch-specific differences. Record the exact source URL and access date for each factual claim. External snippets, schema, and third-party listings may conflict; flag conflicts instead of choosing a value silently.
2. Establish the page decision: improve an existing indexed branch/service page when it already serves the intent; propose a new URL only for a distinct verified service and clear user task. Avoid duplicate city or neighborhood doorway pages. Keep location terms natural and tied to actual operations.
3. Make a fact sheet with columns for claim, branch, source URL, confidence, and merchant-check status. Separate current facts, observed omissions, and hypotheses. Check location names, phone, address, hours, services, availability, photos, booking links, and visible calls to action. A link or heading alone does not prove a service is available; wording such as "coming soon" is not an operating offer.
4. Compare the target page with the other branch. Keep shared brand language concise and draft distinct body copy only from verified differences such as offerings, hours, amenities, menu items, and contact paths. If differences are too thin, improve the existing page rather than inventing local color or landmarks.
5. Draft a unique title, meta description, H1, concise introductory paragraph, useful sections, source-backed FAQ answers only when questions are grounded, and a clear CTA using the actual public destination. Include 2-4 internal links to existing relevant URLs and a suggested image brief with alt text describing verified imagery only. Do not fabricate reviews, awards, prices, accessibility, dietary claims, event capacity, or guarantees.
6. QA every statement against the fact sheet. Do not add structured data fields whose values are missing or contradictory. Label page copy as a draft pending merchant approval. The merchant or site owner owns implementation.
7. For a WordPress site, hand off a field map for the existing Page: page title, permalink or existing URL, body blocks, H1, excerpt if used, featured image and alt text after visual review, SEO title and meta description in the installed SEO plugin if one exists, and internal links. Identify the actual plugin before giving plugin-specific steps. Set the page to draft or preview during implementation and let an authorized merchant editor review before publishing. After publication, fetch the public URL to confirm title, body, canonical, links, and mobile display. Do not claim this Skill executed WordPress changes.

## Required deliverable

Start with an **evidence-based report**: scope/date, URLs inspected, WordPress integration status where relevant, what exists, gaps, conflicts, and confidence limits. Then give a **ranked strategy list** (P1/P2/P3) with the reason each change matters to customer tasks and discoverability; never promise rank gains or a special GEO markup. Follow with an **action plan** table containing action, owner, required input, WordPress field or other implementation location, check, and expected observable result. Include the full **page draft** (suggested URL or existing URL, title, description, headings, copy, CTA, and internal links), a **WordPress-ready field map** when applicable, and a **claim ledger** mapping material claims to source URLs or merchant verification. End with open merchant questions and a publish checklist. If critical facts cannot be verified, produce the report and a clearly marked partial draft, not invented copy.

For GEO, favor clear, crawlable, accurate answers to real customer questions. Treat AI citation presence as something to measure later; writing a page does not establish that any answer engine will cite it.