Optimisation des menus et services locaux

# Local Menu and Service Optimizer

## Task and boundary

Turn a public menu PDF or public service page into a reviewable, searchable HTML content draft for a specific local-business branch. Deliver a sourced report, ranked optimization strategies, operable actions, and draft page sections. Merchant sign-in is unnecessary for public reading and drafting. Do not edit the website, replace a live PDF, post content, or assert that a page will rank or appear in AI answers.

## Loadout capabilities

Use <action-tag>api:tinyfish_api:fetch_urls</action-tag> to read the public branch page, menu PDF URL, and relevant service pages. It can return extracted PDF text. Preflight first, use a small URL batch, and preserve the original merchant URL as the source if the fetcher follows an asset redirect. If unavailable, use a public browser or PDF reader and document the substitute. Extracted PDF text is only a transcription candidate: inspect the rendered PDF or seek merchant confirmation for prices, typography, allergens, modifiers, and columns that can be lost in extraction. 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 connected application. Its currently available Action reads published posts, not Page records or media, and supplies no page-write operation. The WordPress connection is optional for public research and drafting. Record this boundary and create a manual CMS handoff instead of calling an unsupported write.

## Inputs

- Merchant domain, branch, exact public menu or service URL, output language, and desired customer action.
- Optional merchant-approved menu source file, last-updated date, item availability, prices, dietary/allergen wording, and service details.
- Optional target queries, which must be matched to actual offerings instead of dictating menu wording.

## Workflow

1. Read the branch page, linked PDF, and relevant service/contact page. Confirm the PDF belongs to this branch and record source URL, access date, and extraction method. Stop if the menu identity is unclear. Do not mix items from another branch or from delivery-platform listings without a clear reconciliation.
2. Build a source ledger for each proposed item or service: original name, English or Chinese name if present, description, category, price if legible, source page, and confidence. Preserve the merchant's spelling in the ledger; suggest corrections separately. Treat OCR/PDF text-order artifacts, missing prices, "market price," old dates, and uncertain availability as review flags.
3. Compare visible branch HTML with the PDF/service content. Identify a small set of high-value gaps: a text-only PDF that hides menu text from normal page reading, generic service copy, missing branch CTA, unclear menu navigation, stale or contradictory details. Do not claim that a PDF is unindexed without a search-index check. Do not infer allergen-free, vegetarian, spice, or nutrition status from ingredients alone.
4. Draft semantic HTML content: one H1, navigable category headings, concise item names and source-backed descriptions, branch context, and a link to the original full PDF. Use the correct branch reservation/order/contact URL. For uncertain prices, omit them from the public draft and note the verification need. Keep menu text accessible in normal HTML, not solely in images or accordions hidden from all readers.
5. For service pages, draft concrete eligibility, logistics, and next steps only from verified source claims. If an event room says "coming soon," do not present it as bookable. Avoid creating duplicate near-identical branch pages. Keep titles and meta descriptions natural.
6. Perform a line-by-line source QA on a representative sample and all prominent claims. Mark the output as a merchant-review draft. The merchant decides what to publish and checks current prices, availability, and legal notices.
7. For WordPress, map the approved text to a Page: existing Page ID or proposed permalink, page title, body blocks with semantic headings, menu jump links, PDF media URL, branch CTA, image alt text after visual review, and SEO title/meta description in the installed plugin if one exists. Identify the plugin before plugin-specific directions. A merchant editor should preview the draft and verify responsive layout before publishing. After publication, fetch the public URL and confirm HTML item text, links, canonical, and rendered appearance. This Skill does not execute WordPress changes.

## Required deliverable

Provide an **evidence-based report** with inspected URLs, date, WordPress integration status where relevant, verified menu/service facts, extraction limitations, and gaps. Give **P1/P2/P3 strategies** tied to customer questions and specific site surfaces. Then provide an **action plan** table with action, owner, input needed, WordPress field or other implementation location, check, and expected observable result. Include a **complete sample HTML content draft** or a clearly scoped section draft, a title and meta description, internal links, a **WordPress-ready field map** when applicable, and a **source ledger** for every represented item or service. List merchant verification questions and a prepublication checklist. If the PDF cannot be read reliably, produce the report and a limited draft from confirmed facts; do not fabricate missing menu data.

For GEO, make the menu and services easy for people and retrieval systems to understand through accurate headings and direct answers. This is content hygiene, not a guarantee of AI recommendation or citation.