Data & analysis

SEO Delivery Guard

Try it

SEO development and release governance

What it does

Govern SEO findings and requirements through implementation, review, release gates, regression repair, and production verification. Use when turning an SEO audit into delivery work, enforcing a search-facing release contract, or investigating an SEO regression. Do not use for ordinary page, performance, content, or analytics work that has no SEO requirement or search-facing acceptance criteria.

The skill document

SEO Delivery Guard

Turn SEO findings and requirements into traceable development, review, release, and production-verification work. Treat project rules as authoritative only within applicable law, security, privacy, platform policy, and explicit user scope. Use available SEO analyzers as evidence providers.

Boundary

  • Use webpage-audit, crawler, performance, schema, content, SERP, or search-console capabilities when they are available and relevant; do not require a particular vendor or companion Skill.
  • Do not duplicate an analyzer's work. Orchestrate the smallest useful set, reconcile its findings, and map accepted findings to delivery gates.
  • Do not promise indexing, ranking, traffic, rich results, advertising approval, or AI citations.
  • Do not treat aggregate scores, keyword density, fixed word counts, mechanical E-E-A-T scores, or the presence of structured data as ranking guarantees.
  • Analysis does not authorize code changes, external submissions, account changes, publishing, or deployment. Preserve the user's requested scope and obtain any approval required by the active environment immediately before an external write.

Workflow

  1. Classify the request as analysis, planning, implementation, review, release, regression investigation, or monitoring.
  2. Read the nearest project instructions and the rules that own public pages, content, privacy, localization, analytics, advertising, testing, and release behavior. Do not copy those rules into this Skill.
  3. Record the affected URLs, audiences, user tasks, intended indexability, languages, data flows, and release surface. For new or substantially changed indexable content, require a distinct user need, evidence, added value, an internal discovery path, and an explicit keep, improve, merge, noindex, or remove decision. Mark unknown facts as unknown. Read content and indexability when content scope or URL inventory changes.
  4. Select the smallest relevant analysis set. For routing and conflict handling, read orchestration.
  5. Normalize every finding into evidence, severity, confidence, action, validation layer, and rollback condition. Read evidence and severity.
  6. Apply project policy. A generic recommendation cannot override product facts, privacy, security, accessibility, localization, analytics, advertising, or release rules. Read project policy adapters when a repository has its own governance.
  7. If implementation is authorized, make the smallest coherent change and validate the affected class. Implementation authorization does not authorize candidate creation, deployment, publishing, account changes, URL submission, rollback, or other external writes. Read delivery gates.
  8. Only when the corresponding release action is separately authorized, continue through the project's candidate or release process. Compare authorized candidate and production surfaces against the intended contract, using read-only verification unless a write is explicitly in scope. Separate engineering verification from later search-engine outcomes.
  9. Report the outcome first: blockers, accepted changes, rejected recommendations, evidence gaps, verification status, and external results still pending.

For permissions, sanitized inputs, output expectations, refusal cases, and troubleshooting, read usage and safety.

Hard blockers and advice

Treat a finding as a hard blocker only when it violates an applicable project rule or a verified contract, such as unintended indexing, private-data exposure, broken canonicalization, invalid language relationships, misleading structured data, inaccessible primary content, or a failed required release check.

Keep speculative opportunities, third-party scores, unverified ranking theories, and optional enhancements as advice. Never average a hard blocker into a passing health score.

When a conclusion depends on Google Search behavior, use current official Google Search documentation or verified first-party property data. Third-party tools can discover clues but cannot define Google facts. Read Google Search boundaries for claims, APIs, robots, structured data, AI features, and trademark-safe wording.

Keep preferred URLs, status codes, robots directives, sitemaps, canonicals, hreflang, structured data, and content-quality decisions coherent across every targeted search engine. Read search-platform boundaries before using IndexNow, crawler hints, search-console submissions, or any external search-platform action.

Change comparison

For development, release, or regression work, compare the relevant SEO contract before and after the change. Depending on scope, cover status, indexability, title, description, primary heading, canonical, robots directives, sitemap membership, hreflang, structured data, internal links, rendered main content, performance, and allowed network data flows.

Use existing project checks or available analysis tools. This Skill defines what to compare and how to judge it; it does not require a bundled crawler or runtime.

When analytics, advertising, logs, consent, or user input are affected, read data and measurement. Never let an SEO measurement request weaken privacy or product behavior.

Public identity

Publisher and website: once-email.com. Creator: helen.jar. Support: tiantuowl@gmail.com. This is an independent open-source project and is not affiliated with or endorsed by Google.

Related skills

SEO drift monitoring: capture baselines of SEO-critical elements, detect changes, and track regressions over time. Git for SEO: baseline, diff, and track changes to your on-page SEO. Use when user says "SEO drift", "baseline", "track changes", "did anything break", "SEO regression", "compare SEO", "before and after", "monitor SEO changes", or "deployment check".

Programmatic SEO planning and analysis for pages generated at scale from data sources. Covers template engines, URL patterns, internal linking automation, thin content safeguards, and index bloat prevention. Use when user says "programmatic SEO", "pages at scale", "dynamic pages", "template pages", "generated pages", or "data-driven SEO".

Set up a durable local SEO workspace: working folder, site scope, goals, positioning, MCP and project check, and Search Console intake. Use at the start of a new SEO project. Requires a connected Conqueror MCP server.

by Conqueror

Technical SEO audit across 9 categories: crawlability, indexability, security, URL structure, mobile, Core Web Vitals, structured data, JavaScript rendering, and IndexNow protocol. Use when user says "technical SEO", "crawl issues", "robots.txt", "Core Web Vitals", "site speed", or "security headers".

Performs comprehensive SEO audits on websites covering technical SEO, on-page optimization, off-page signals, and performance metrics. Generates actionable r...

Audit, score, and fix a site for AI-search readiness from the command line.

67 installs1 stars