fixing-metadata
Skill3 starsChanged 5 months agoMITView on GitHub
Audit and fix HTML metadata including page titles, meta descriptions, canonical URLs, Open Graph tags, Twitter cards, favicons, JSON-LD structured data, and robots directives. Use when adding SEO metadata, fixing social share previews, reviewing Open Graph tags, setting up canonical URLs, or shipping new pages that need correct meta tags.
We split this skill into the rules it gives an agent
22 rules. 21 are common, 0 are distinctive, and 1 is very specific to this project.
21
Common
Most of the 6 edited versions we read keep these.
0
Distinctive
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Common: line 16
Ensure title, description, canonical, and og:url all agree with each other
- Common: line 17
Verify social cards render correctly on a real URL, not localhost
- Common: line 18
Keep diffs minimal and scoped to metadata only — do not refactor unrelated code
- Common: line 48
do not emit duplicate title, description, canonical, or robots tags
- Common: line 51
every page must have safe defaults for title and description
- Common: line 55
every page must have a title
- Common: line 56
use a consistent title format across the site
- Common: line 57
keep titles short and readable, avoid stuffing
- Common: line 64
use noindex only for private, duplicate, or non-public pages
- Common: line 73
prefer correct image dimensions and stable aspect ratios
- Common: line 75
use a sensible og:type, usually website or article
- Common: line 88
do not add JSON-LD unless it clearly maps to real page content
- Common: line 90
do not invent ratings, reviews, prices, or organization details
- Common: line 91
prefer one structured data block per page unless required
- Common: line 97
add hreflang alternates only when pages truly exist
- Common: line 102
prefer minimal changes, do not refactor unrelated code
- Common: line 103
do not migrate frameworks or SEO libraries unless requested
- Very specific: line 104
follow the project's existing metadata pattern (Next.js metadata API, react-helmet, manual head, etc.)
- Common: line 109
ensure title, description, canonical, and og:url agree
- Common: line 110
verify social cards on a real URL, not localhost
- Common: line 111
prefer stable, boring metadata over clever or dynamic
- Common: line 112
keep diffs minimal and scoped to metadata only
“Common” is measured: kept by at least 6 in 10 of the 6 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Workflow
- Identify pages with missing or incorrect metadata (titles, descriptions, canonical, OG tags)
- Audit against the priority rules below — fix critical issues (duplicates, indexing) first
- Ensure title, description, canonical, and og:url all agree with each other
- Verify social cards render correctly on a real URL, not localhost
- Keep diffs minimal and scoped to metadata only — do not refactor unrelated code
when to apply
Reference these guidelines when:
- adding or changing page titles, descriptions, canonical, robots
- implementing Open Graph or Twitter card metadata
- setting favicons, app icons, manifest, theme-color
- building shared SEO components or layout metadata defaults
- adding structured data (JSON-LD)
- changing locale, alternate languages, or canonical routing
- shipping new pages, marketing pages, or shareable links
rule categories by priority
| priority | category | impact |
| 1 | correctness and duplication | critical |
| 2 | title and description | high |
| 3 | canonical and indexing | high |
| 4 | social cards | high |
| 5 | icons and manifest | medium |
| 6 | structured data | medium |
| 7 | locale and alternates | low-medium |
| 8 | tool boundaries | critical |
quick reference
1. correctness and duplication (critical)
- define metadata in one place per page, avoid competing systems
- do not emit duplicate title, description, canonical, or robots tags
- metadata must be deterministic, no random or unstable values
- escape and sanitize any user-generated or dynamic strings
- every page must have safe defaults for title and description
2. title and description (high)
- every page must have a title
- use a consistent title format across the site
- keep titles short and readable, avoid stuffing
- shareable or searchable pages should have a meta description
- descriptions must be plain text, no markdown or quote spam
3. canonical and indexing (high)
- canonical must point to the preferred URL for the page
- use noindex only for private, duplicate, or non-public pages
- robots meta must match actual access intent
- previews or staging pages should be noindex by default when possible
- paginated pages must have correct canonical behavior
4. social cards (high)
- shareable pages must set Open Graph title, description, and image
- Open Graph and Twitter images must use absolute URLs
- prefer correct image dimensions and stable aspect ratios
- og:url must match the canonical URL
- use a sensible og:type, usually website or article
- set twitter:card appropriately, summary_large_image by default
5. icons and manifest (medium)
- include at least one favicon that works across browsers
- include apple-touch-icon when relevant
- manifest must be valid and referenced when used
- set theme-color intentionally to avoid mismatched UI chrome
- icon paths should be stable and cacheable
6. structured data (medium)
- do not add JSON-LD unless it clearly maps to real page content
- JSON-LD must be valid and reflect what is actually rendered
- do not invent ratings, reviews, prices, or organization details
- prefer one structured data block per page unless required
7. locale and alternates (low-medium)
- set the html lang attribute correctly
- set og:locale when localization exists
- add hreflang alternates only when pages truly exist
- localized pages must canonicalize correctly per locale
8. tool boundaries (critical)
- prefer minimal changes, do not refactor unrelated code
- do not migrate frameworks or SEO libraries unless requested
- follow the project's existing metadata pattern (Next.js metadata API, react-helmet, manual head, etc.)
review guidance
- fix critical issues first (duplicates, canonical, indexing)
- ensure title, description, canonical, and og:url agree
- verify social cards on a real URL, not localhost
- prefer stable, boring metadata over clever or dynamic
- keep diffs minimal and scoped to metadata only
Trending
Steady: 0 new projects took it in the last 4 weeks, none the 4 weeks before.thin data
Other versions9 projects use a version of this.
Word for word · 3
- ibelick/ui-skills★ 10k100% same
- master5d/claude-design-skills★ 26100% same
- julianromli/faiz-skills★ 16100% same
Edited · 5
- agentset-ai/agentset★ 2.1k87% same
- kapishdima/soundcn★ 86487% same
- hsynozdamar-byte/claude-skills-edited★ 496% same
- ClaireAll/skills★ 295% same
- sanmidable/skills★ 296% same
Wrote their own version · 1
- jscraik/Agent-Skills★ 9same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
Used alongsideProjects with it also use create-design-md, better-interface and 7 more.
Other files people use alongside this one.
Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
ItamarZand88Skillcreate-design-md
Create a new DESIGN.md file for any website, app, or custom design system. Use when the user wants to document a design system in DESIGN.md format, extract design tokens from a URL or existing CSS, create a custom design system from scratch, author a DESIGN.md for their own project, or contribute a new design to the awesome-design-md collection. Also trigger when user mentions "design system documentation", wants to formalize their app's visual language, or asks to create or generate a DESIGN.md file.
Also in 4 projects that use this
AnasX7Skillbetter-interface
Combines all of the `better-*` skills into a single review across accessibility, layout, writing, typography, color and UI polish.
Also in 3 projects that use this
AnasX7Skillbetter-accessibility
Helps your project comply with accessibility standards and best practices.
Also in 3 projects that use this
VercelSkillemil-design-eng
This skill encodes Emil Kowalski's philosophy on UI polish, component design, animation decisions, and the invisible details that make software feel great.
Also in 4 projects that use this
- +5 more from AnasX7
In this repository5 other files it gives its agents.
- baseline-uiSkill
- fixing-accessibilitySkill
- fixing-motion-performanceSkill
- improve-uiSkill
- ui-skills-rootSkill
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
Reviews can't be read right now.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

