/seo-landing

name: seo-landing
description: "Generates fast, SEO-optimized static HTML landing pages targeting 100/100 PageSpeed (LCP < 2.5s, INP < 100ms, CLS < 0.1), full schema.org JSON-LD, AVIF images, critical CSS, zero external dependencies. Use when: user asks to create/build/generate a landing page, one-pager, or static site with focus on SEO, speed, or PageSpeed; asks for an SEO-friendly page from a brief/ТЗ; or asks to audit/fix a landing against a performance checklist."
metadata:
  argument-hint: "[topic/domain or brief]"

SEO Landing Generator

Builds a static single-page HTML landing optimized for 100/100 PageSpeed and maximum SEO: critical CSS, AVIF images, full JSON-LD structured data, native-only interactivity, zero third-party requests on first load.

When to Use

• User asks for a landing page / one-pager focused on speed and SEO → **generate** mode.
• User provides a brief (ТЗ) and wants a production-ready static page → **generate** mode.
• User asks to audit an existing landing against the checklist without changes → **audit-only** mode (§0b, read-only, no project files).
• User asks to fix/improve an existing landing → **fix-existing** mode (§0c).

Procedure

0. Route the request to a mode first

The skill serves three modes — pick one from the request (ask if ambiguous), because each mode collects different inputs and produces different output:

• **generate** — build a new landing page from a brief ("build/create/generate a landing…"). Runs the full procedure below.
• **audit-only** — read-only inspection of an existing page ("audit/check/review this landing against the checklist…", no changes requested). Runs §0b. Never writes project files.
• **fix-existing** — apply targeted fixes to an existing page ("fix/improve/optimize this page…"). Runs §0c.

Representative routing:

• "Build a landing for a dental clinic from this brief" → **generate**.
• "Audit https://example.com/ against the performance checklist and report what's wrong" → **audit-only**.
• "This landing's hero image shifts on load — fix it" → **fix-existing**.

Generation-only brief fields (target keywords, business type, CTA, media facts) are collected ONLY for generate and rebuild work. An audit or a targeted fix must not be blocked or delayed by missing generation inputs, and audit-only mode must not create or modify any project files.

0a. Collect the brief (generate mode; ask if missing)

Required before generating anything:

• Domain / final URL — for canonical, og:url, absolute paths, JSON-LD `@id`.
• Site identity (for `WebSite` markup, only when the page is the domain/subdomain home page): preferred site name, optional alternate names, and the canonical home URL — collected separately from the landing URL.
• Breadcrumb trail (for `BreadcrumbList` markup, only when a real site hierarchy exists): the visible breadcrumb trail and canonical parent URLs.
• Page language, base direction, and Open Graph locale — three separate inputs, never one value copied across formats: a BCP-47 language tag for `<html lang>` (e.g. `en-US`, `ar-SA`), the base direction (`ltr`/`rtl` — RTL documents get `dir="rtl"` on `<html>`, and `lang` alone does not set directionality), and the Open Graph locale in `language_TERRITORY` format for `og:locale` (e.g. `en_GB`). Ask when direction is unknown for an RTL-capable language (tech-spec §2).
• Topic + 1–3 target keywords — for H1, title, description.
• Business type: Organization or LocalBusiness. For LocalBusiness collect the verified public/legal business name and the complete structured postal address (street, locality, region, postal code, country), plus phone and geo coordinates. Also collect the verified schema.org subtype(s) based on the actual business (e.g. `Restaurant`, `Dentist`, `HardwareStore`) — never chosen from target keywords. Never invent missing identity facts: fall back to `Organization` markup or omit entity markup until the facts are provided.
• CTA and contacts (phone, form, messengers). When a form is requested, also collect its submission destination and method (a first-party endpoint or a documented form service — never invented), the consent/privacy text required for the collected personal data, and where submissions are stored and who owns them; with no destination, the form is omitted or explicitly stubbed (tech-spec §10 form submission contract).
• A brand-approved favicon or explicit permission to create one — never invent a brand mark silently.
• Approved source material and a claim owner for objective marketing facts (numbers, prices, qualifications, guarantees, comparisons, case studies) — without them such claims are omitted, never invented.
• Whether images are provided; whether FAQ / reviews / video blocks are needed. For a video block collect source-backed facts: video URL/ID, title, description, accurate first-publication date/time with timezone, and a unique crawlable thumbnail (plus `contentUrl` when applicable). Never invent missing media facts. Also collect the video mode with its trade-off stated: click-only facade (default — privacy/performance; the page will not satisfy Google's video discovery requirements and no video-search benefit is claimed) or SEO-discoverable (self-hosted `<video>` or a documented direct embed — required when video search traffic matters) (tech-spec §9).

If domain or keywords are missing — ask first, do not invent them.

0b. Audit-only mode (read-only)

Audit an existing page without generating a replacement. No project files are created or modified in this mode — the deliverable is a report.

1. Identify the target: a deployed URL (preferred — lets every check run against reality) or local HTML files. If neither is supplied, ask; never guess the target. 2. Run the applicable checks from §5 against the target as-is: W3C validity, local asset existence (for local files), JSON-LD via a schema.org validator, Lighthouse against the served/deployed URL, crawlability contract (robots.txt + sitemap.xml