seo-landing

Name: seo-landing
Author: aleksandr-alhoff

Pending

SEO Landing: Give your AI coding agent the capabilities of a senior Technical SEO engineer. An agent skill for building high-performance, technically optimized SEO landing pages. Turn an AI coding agent into a technical SEO specialist. Build and improve landing pages with: • 🚀 100/100 Google PageSpeed target • ⚡ Core Web Vitals optimization

51stars

5forks

HTML

Installation

# Add to your Claude Code skills
git clone https://github.com/aleksandr-alhoff/seo-landing

Getting Started

Guides for using ai agents skills like seo-landing.

SKILL.md

README.md

Frequently Asked Questions

What is seo-landing?

seo-landing is an open-source ai agents skill for AI coding assistants such as Claude Code, Codex CLI, and ChatGPT, built by aleksandr-alhoff. SEO Landing: Give your AI coding agent the capabilities of a senior Technical SEO engineer. An agent skill for building high-performance, technically optimized SEO landing pages. Turn an AI coding agent into a technical SEO specialist. Build and improve landing pages with: • 🚀 100/100 Google PageSpeed target • ⚡ Core Web Vitals optimization. It has 51 GitHub stars.

Is seo-landing safe to use?

seo-landing's catalog security scan is still queued. You can run an instant dependency and prompt-injection check now with the "Scan for vulnerabilities" button above.

How do I install seo-landing?

Clone the repository with "git clone https://github.com/aleksandr-alhoff/seo-landing" and add it to your Claude Code skills directory (see the Installation section above). seo-landing ships a SKILL.md manifest, so compatible agents can discover and load it automatically.

What programming language is seo-landing written in?

seo-landing is primarily written in HTML. It is open-source under aleksandr-alhoff on GitHub, so you can review or fork the full source.

Are there alternatives to seo-landing?

Yes. SkillsLLM lists many other AI Agents skills you can browse and compare side by side. Open the AI Agents category from the badge at the top of this page, or use the Related Skills and comparison links further down to weigh seo-landing against similar tools.

Agentic AI for Beginners

Build your first AI agent from scratch - tool use, ReAct pattern, memory, deployment

41 minBeginner

Comments (0)

to leave a comment.

No comments yet. Be the first to share your thoughts!

Related Skills

ECC

by affaan-m

The agent harness performance optimization system. Skills, instincts, memory, security, and research-first development for Claude Code, Codex, Opencode, Cursor and beyond.

244,413

refine-canvas-strokes CiteCheck

⚠️ Third-Party Software Notice

This skill is third-party open-source software developed and hosted independently on GitHub. SkillsLLM is an informational directory and does not control or maintain the underlying repository.

Any security checks, ratings, or warnings displayed by SkillsLLM are automated and limited in scope. They do not constitute a security certification or guarantee that the software is safe, error-free, or free from malicious code, vulnerabilities, compromised dependencies, or prompt-injection risks.

Review the source code, permissions, dependencies, and configuration before installing or running any third-party skill. Use is at your own risk. To the maximum extent permitted by applicable law, SkillsLLM is not liable for losses arising from third-party software.

Read the Terms of Service

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.

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.
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 at the deployed host), and the manual accessibility checks in tech-spec §8.
Report evidence per check: pass/fail with the measured value or observed markup, and the exact command/tool used. Where a check cannot run (no deployed URL for Lighthouse, no robots.txt on the host), report a blocker for that check — do not estimate, extrapolate, or omit it silently.
Distinguish syntax validity from Google feature eligibility (FAQPage, VideoObject, rich results): valid markup is reported as valid markup, never as an achieved search feature.
Optionally end with a prioritized fix list. Applying fixes is a separate fix-existing request — do not start editing without it.

0c. Fix-existing mode

Apply targeted fixes to an existing page without a full rebuild.

Identify the page/files and the specific problems to fix; collect only the inputs those fixes need (never the full generation brief).
Apply each fix per the relevant tech-spec section, preserving unrelated markup and content.
STOP POINT (§4) applies: show the changed page before validation. If fixes change what the user approved earlier, obtain renewed approval before reporting.
Validate the changed page (§5) and report measured evidence only.

Generation workflow (generate mode)

1. Create the project folder

Every project lives in its own folder inside the workspace — never write to the workspace root. The output is a multi-file project: every local resource referenced by the HTML must exist as a real file.

<workspace>/<project-slug>/
  index.html        # the generated landing page
  styles.css        # only when below-the-fold CSS is deferred (§1); absent when all CSS is inlined
  script.js         # only when the page uses JS (§10); single file, defer
  images/           # every image variant referenced in src/srcset/preload/OG tags (AVIF/WebP/JPEG, all breakpoints)
  favicon.png       # stable square brand icon, ≥48×48
  ASSETS.md         # rights & provenance record for every asset
  robots.txt
  sitemap.xml
  SERVER-SETUP.md   # hosting instructions

Image branch:

Images provided in the brief → produce all required variants (AVIF/WebP/JPEG at every breakpoint named in srcset) from them.
No images available → request them from the user or omit the image/block. Never emit a successful-looking asset URL without producing the file or explicitly asking for it — a referenced-but-missing file is a generation failure, not a placeholder.

2. Generate the page

Build index.html strictly following references/tech-spec.md — 13 requirement sections (performance, HTML structure, SEO, security, CSS/fonts, forbidden list, testing, accessibility, embedded video, typical blocks, deferred widgets, content truthfulness & provenance, input sanitization & output encoding).

Treat every brief value as untrusted: encode it for its exact output context (HTML text, attribute, URL, JSON-LD), allow-list URL schemes (reject javascript:/unexpected data:), escape < in serialized JSON-LD, and validate structured IDs (e.g. YouTube ^[A-Za-z0-9_-]{11}$) before they reach any URL (tech-spec §13).

For embedded YouTube video use the facade pattern by default; the SEO-discoverable mode (self-hosted <video> or a documented direct embed) is an explicit brief choice with a disclosed trade-off, never a silent switch — rules and the Google discovery requirements in tech-spec §9, facade reference implementation in references/video-facade.md. Maps follow the facade rule only (tech-spec §10): a local screenshot in the initial DOM, the iframe inserted only on explicit activation — never a native loading="lazy" map iframe. Reference: references/map-facade.md.

3. Generate companion files

robots.txt at the site root with a fully qualified Sitemap: line, never blocking the canonical page or required media.
sitemap.xml with XML-escaped absolute canonical <loc> URLs matching the HTML canonical; lastmod only from a verifiable significant-content-change timestamp (omit when unknown — never use generation time blindly).
Hosting instructions from references/server-config.md: caching, Brotli/gzip, security headers.

4. STOP POINT — user approval

Show the generated page to the user and ask explicitly whether the HTML version is OK. Do not proceed to validation and the final report until the user confirms. If there are remarks — fix and ask again.

5. Validate

Run the executable validation contract from tech-spec §7 — pinned commands against the served page, measured results only, explicit BLOCKER when a gate cannot run:

W3C HTML validity (Nu validator, JSON output; zero errors).
Local asset/link existence: extract every local URL referenced by the output (img src/srcset, <source> srcset, preload href/imagesrcset, favicon, OG/Twitter images, CSS url(), script src) and verify each file exists in the project folder. Any missing referenced local resource is a hard failure — produce the file or remove the reference; never ship HTML pointing at files that were never created.
JSON-LD syntax (JSON parse) — separate from Google rich-result eligibility, which is checked with Rich Results Test on the deployed page.
Responsive screenshots at 320/768/1280/1920px, inspected for overflow and reflow.
Lighthouse: pinned version/profile, 3 runs, median per category, threshold ≥ 90, artifacts kept in the project's reports/ — lab evidence only, never field Core Web Vitals and never WCAG certification.
Manual accessibility checks (tech-spec §8) — no automated tool alone determines WCAG conformance: keyboard navigation, focus order/visibility, dialog focus flow, zoom/reflow, reduced motion, semantic name-role-value, alternative-text quality, and all interactive visual states. Record pass/fail evidence per applicable WCAG 2.1 AA criterion; report unresolved items instead of silently certifying them.
Crawlability contract: parse sitemap.xml, compare every <loc> with the HTML canonical, check the Sitemap: URL in robots.txt, and request both deployed files successfully (HTTP 200).

Fix any violations found before reporting. Disclose evidence honestly: every reported number comes with the exact command and artifact path that produced it; a gate that could not run is reported as BLOCKER: <reason> instead of a number. Never output a PageSpeed/LCP score that was not actually measured.

6. Final report

Briefly list:

LCP parameters
PageSpeed score
schema.org types used in the code

Main pitfalls

Never use external JS/CSS libraries, external fonts, or SVG images (tech-spec §6).
Never reference a local asset that was never created: every src/srcset/preload/OG URL must resolve to a real file in the project folder; missing source images are requested from the user, not invented (OUTPUT contract).
Never emit a raw brief value into markup: context-encode everything, reject javascript:/unexpected data: URLs, and self-test generation with hostile values (quotes, </script>, event-handler payloads) (tech-spec §13).
Never load YouTube iframes, maps, chats, subscription popups, or cookie banners on first load (tech-spec §9, §10, §11) — the single documented exception is a brief-chosen SEO-discoverable video mode with a direct embed recorded as a first-load dependency (tech-spec §9 Mode S).
All content must exist in raw HTML — nothing rendered only by JS.
Absolute URLs in JSON-LD, canonical, and OG tags.
Total JS budget ≤ 15 KB, one file, defer before </body>.

SEO Landing

Give your AI coding agent the capabilities of a senior Technical SEO engineer.

An agent skill for building high-performance, technically optimized SEO landing pages. Turn an AI coding agent into a technical SEO specialist.

Build and improve landing pages with:

🚀 100/100 Google PageSpeed target
⚡ Core Web Vitals optimization
🔍 Technical SEO
🧩 Full Schema.org structured data
🖼️ AVIF image optimization
🎨 Critical CSS
🧹 Zero third-party requests on first load
📱 Mobile-first performance
🤖 Semantic HTML

🇷🇺 Описание скила на русском языке

Works with AI coding agents

Designed for agentic coding workflows and compatible with Agent Skills–style environments.

What it does?

The skill guides an AI coding agent through the complete landing-page workflow:

Analyze the existing page
Fix technical SEO issues
Optimize HTML structure
Improve Core Web Vitals
Optimize images and fonts
Add structured data
Remove unnecessary dependencies
Validate the final implementation

Why?

AI can generate a beautiful landing page in seconds. The problem is that generated pages often contain:

unnecessary JavaScript
oversized images
poor semantic structure
missing structured data
weak metadata
performance bottlenecks
technical SEO mistakes

SEO Landing Skill gives the agent a repeatable technical SEO workflow instead of relying on generic prompting.

An agent skill that builds and updates landing pages toward 100/100 lab PageSpeed and Core Web Vitals-friendly performance, and gets the technical SEO right. Static HTML, critical CSS, AVIF images, full schema.org markup, zero third-party requests on first load (deferred widgets, when used, are consent-gated and documented in the dependency manifest). These are optimization targets, not guaranteed outcomes — results depend on content, hosting, devices, and real traffic; Core Web Vitals status itself is determined by Google from field (RUM) data, not by lab tools.

BEFORE
Landing page
↓
LCP: 4.2s
Performance: 61
Missing schema
Large PNG
Render-blocking CSS

        ↓ SEO LANDING SKILL ↓

AFTER
Landing page
↓
LCP: 1.1s
Performance: 100
Schema.org ✓
AVIF ✓
Critical CSS ✓
Semantic HTML ✓

Format — Agent Skills (open standard originally developed by Anthropic): works in VS Code Copilot, Claude Code, OpenAI Codex, Google Antigravity, Cursor, Gemini CLI, OpenClaw, Hermes, and other compatible agents.

What's inside

seo-landing/
├── SKILL.md              # Main workflow: mode routing → brief → generation → stop point → validation → report
├── references/
│   ├── tech-spec.md      # Technical spec (13 requirement sections + executable validation contract)
│   ├── server-config.md  # Server config: caching, Brotli/gzip, security headers (Nginx/Apache)
│   ├── video-facade.md   # Reference implementation of the "facade" pattern for YouTube
│   └── map-facade.md     # Reference implementation of the "facade" pattern for map embeds
├── benchmark/            # Lab benchmark disclosure: fixture, raw Lighthouse reports, methodology
└── tests/
    └── fixtures/broken-landing/  # Negative fixture: every validator gate must fail on it

Key requirements enforced by the skill

Performance: LCP < 2.5s, INP < 100ms, CLS < 0.1; critical CSS inlined, the rest loaded async; the LCP image loads eagerly with fetchpriority="high" (a responsive imagesrcset/imagesizes preload only when measurement shows a benefit)
Images: AVIF → WebP → JPEG via <picture>, srcset/sizes, width/height, loading="lazy" for below-the-fold images only (never on the LCP image), breakpoints 320–1920
SEO: title/description/canonical/robots, Open Graph, Twitter Card, JSON-LD (WebSite, Organization, BreadcrumbList, FAQPage, VideoObject — emitted only when fact-backed and reported per the chosen video mode, never as a guaranteed search feature)
Accessibility: WCAG 2.1 AA, contrast ≥ 4.5:1, keyboard navigation, prefers-reduced-motion
Security: X-Content-Type-Options, X-Frame-Options, Permissions-Policy, Referrer-Policy, per-page CSP, staged HSTS, HTTPS enforcement, rel="noopener noreferrer"
Fonts: system fonts only — no external fonts, no Google Fonts
JS budget ≤ 15 KB for the first load, one file with defer; deferred third-party widgets (when used) are consent-gated, excluded from the budget, and disclosed in the dependency manifest
Forbidden: external JS/CSS libraries, SVG images, synchronous scripts, iframes on first load
Video & maps: "facade" pattern by default — the cover is a local responsive image (eager when it is the LCP/above the fold, lazy below the fold), the iframe loads only on click. Click-only video trades Google video discovery for pre-activation privacy/performance; an opt-in SEO-discoverable mode (self-hosted <video> or a documented direct embed) exists when video search matters (tech-spec §9). Maps remain facade-only.
Common blocks without JS: FAQ via <details>, slider via scroll-snap, modal via <dialog>
Stop point: before validation and the final report, the skill always asks the user to confirm the HTML version

Real-world result (lab measurements — not field Core Web Vitals)

One reproducible lab benchmark: Lighthouse CLI 13.4.1, mobile emulation, simulated throttling. Original — an Angular SPA (102 requests, 1 run); the same page rebuilt as static HTML with this skill (17–18 requests, median of 5 runs). Full disclosure — fixture, exact flags, raw JSON reports, timestamps, and aggregation method — is in benchmark/README.md.

Metric	Original	Rebuilt	Gain
Performance	75	100	+25
Accessibility	75	100	+25
Best Practices	73	100	+27
LCP	3.3 s	1.6 s	−52%
Total Blocking Time	490 ms	13 ms	−97%
TTI	9.4 s	1.6 s	−83%
Data transferred	769 KiB	110 KiB	−86%
Requests	102	17	−83%

These are lab numbers for one before/after pair. They are not field Core Web Vitals (Google determines CWV status from CrUX/RUM field data at the 75th percentile, and Lighthouse cannot measure INP without real interaction), and they are not a guarantee that another page, host, device, or audience will reach the same results — the skill's targets are optimization goals, not promised outcomes.

Installation

The skill is hosted at github.com/aleksandr-alhoff/seo-landing. Clone the repository — the repo root is the skill folder itself — then run the commands below from the directory that contains seo-landing/:

git clone https://github.com/aleksandr-alhoff/seo-landing.git

Global (available in all projects)

Every recipe below is self-contained: it creates its destination directory first, then copies the skill into it. Each one must exit with status 0 and leave the layout <skills-dir>/seo-landing/SKILL.md in place.

Note: cp -R from a git clone also copies the clone's .git directory into the installation — harmless, but unnecessary. To keep installations lean, replace cp -R seo-landing <dir>/ with rsync -a --exclude=.git seo-landing <dir>/seo-landing/ (the same sync used for updates below).

# VS Code Copilot
mkdir -p ~/.copilot/skills
cp -R seo-landing ~/.copilot/skills/

# Claude Code
mkdir -p ~/.claude/skills
cp -R seo-landing ~/.claude/skills/

# OpenAI Codex CLI / ChatGPT desktop
mkdir -p ~/.agents/skills
cp -R seo-landing ~/.agents/skills/

# Cursor
mkdir -p ~/.cursor/skills
cp -R seo-landing ~/.cursor/skills/

# Gemini CLI
mkdir -p ~/.gemini/skills
cp -R seo-landing ~/.gemini/skills/

# Google Antigravity
mkdir -p ~/.gemini/config/skills
cp -R seo-landing ~/.gemini/config/skills/

# OpenCode
mkdir -p ~/.config/opencode/skills
cp -R seo-landing ~/.config/opencode/skills/

# OpenClaw (via CLI — installs into the shared ~/.openclaw/skills)
openclaw skills install git:aleksandr-alhoff/seo-landing --global
# or from a local clone: openclaw skills install ./seo-landing --global
# or manually:
mkdir -p ~/.openclaw/skills
cp -R seo-landing ~/.openclaw/skills/

# Hermes
mkdir -p ~/.hermes/skills
cp -R seo-landing ~/.hermes/skills/

OpenClaw also picks up skills from ~/.agents/skills (the Codex path above), and Hermes can scan it too if you add ~/.agents/skills to skills.external_dirs in ~/.hermes/config.yaml.

Gemini CLI can also install straight from a Git repository:

gemini skills install https://github.com/aleksandr-alhoff/seo-landing.git

Per project (workspace only)

# Shared .agents/skills — picked up by VS Code Copilot, Codex, Cursor, Antigravity, Gemini CLI, OpenCode, OpenClaw, Hermes
mkdir -p .agents/skills
cp -R seo-landing .agents/skills/

# Claude Code
mkdir -p .claude/skills
cp -R seo-landing .claude/skills/

# VS Code Copilot (GitHub-style location)
mkdir -p .github/skills
cp -R seo-landing .github/skills/

# OpenClaw (workspace skills — highest precedence)
# via CLI: openclaw skills install ./seo-landing
mkdir -p skills
cp -R seo-landing skills/

# Hermes (project-local; then trust the repo once: hermes skills trust)
mkdir -p .hermes/skills
cp -R seo-landing .hermes/skills/

Updating, verifying, and uninstalling installed copies

Two facts drive everything below:

git pull changes only the clone. An installed copy made with cp -R is independent — pulling the source clone does NOT update any installation.
cp -R copies, it does not synchronize. GNU cp has no destination-sync/removal behavior: a file deleted upstream stays in the installed copy forever, producing a mixed release of old and new instructions.

So an update is an explicit, bounded, idempotent sync into the resolved skill destination — never a blind re-copy.

Destinations (one per client and scope)

| Client /