improve-seo
Skill0 starsChanged 2 months agoMITView on GitHub
Audits a project's public web surface and fixes it — target search terms, page metadata, descriptive URLs, crawlability, structured data, image alt text, and internal and outbound links. Use when a site should rank, or before launching one.
In this repository16 other files it gives its agents.
- adversarial-reviewSkill
- changelogSkill
- cve-patchSkill
- diagnoseSkill
- docs-driftSkill
- good-readmeSkill
- improve-designSkill
- janitorSkill
- kickoffSkill
- nta-scanSkill
- refactor-oopSkill
- repo-reconSkill
- software-architectureSkill
- spec-driven-devSkill
- stack-adviseSkill
- your-skill-nameSkill
The file
We split this skill into the rules it gives an agent
5 rules. About 0 are common, 5 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈5
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 10
Every indexable page of this project carries a stated target query, a unique title and description, a canonical URL, a descriptive path, …
- Distinctive: line 113
Never change a published URL without a 301 in the same change.
- Distinctive: line 114
No manipulation: no keyword stuffing, hidden text, cloaking, doorway pages, bought or exchanged links, or structured data describing things …
- Distinctive: line 122
Don't add analytics, tag managers, consent banners, or any third-party script.
- Distinctive: line 126
Don't guess the production domain, brand name, or company details.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Improve SEO
Goal
Every indexable page of this project carries a stated target query, a unique title and description, a canonical URL, a descriptive path, correct structured data, alt text on every image, and working links in both directions — with a table saying what each page is now trying to rank for.
Context
Check first:
- Whether there is a public web surface at all. A library, CLI, or private service has no pages to optimise; say so and stop rather than inventing work. Its registry listing and repository metadata are still in scope (step 9).
- What the project is and who it is for (README, landing copy, docs). That is where target search terms come from — you do not get to invent them.
- The stack and its metadata API: Next.js
metadataexports ornext-seo, Astro layouts, NuxtuseSeoMeta, SvelteKit<svelte:head>, Hugo/Jekyll front matter and config, Gatsby Head API, or a plain template partial. Use the one the project already has instead of adding a second mechanism. - The route table or content tree, and whether pages are server-rendered, static, or client-rendered. Client-rendered content is the common cause of a site with no indexable text at all.
- The canonical production origin — scheme, host,
wwwor apex, trailing slash. Every absolute URL you write depends on it. Ask if it is not in the config, and never guess a domain. - What already exists:
robots.txt,sitemap.xml, canonical tags, JSON-LD, redirect rules (_redirects,netlify.toml,vercel.json,.htaccess, nginx config), and any analytics or Search Console verification.
Steps
- Build the site and read the rendered HTML, not the templates. What the
crawler sees is the output. Record a baseline: pages missing a title,
description, canonical,
h1, orlang, and images missingalt. - Target terms: give each page one primary query and a few supporting ones, drawn from the project's own vocabulary and the problem it solves. Match intent to page type — informational for docs, commercial for the pricing page. One page per intent: two pages chasing the same query compete with each other, so merge or differentiate them.
- Metadata, per page and unique: a
<title>of roughly 50–60 characters leading with the primary term and ending with the brand; a meta description of roughly 150–160 written to earn the click, not to repeat the title; an absoluterel=canonical;langon<html>; Open Graph and Twitter tags with an image that exists and is reachable at an absolute URL. - Headings: exactly one
h1per page, stating what the page is; no skipped levels below it; headings that describe the section rather than decorate it. - Descriptive URLs: lowercase, hyphenated, word-based paths that read as the
page's subject —
/docs/rate-limiting, not/p?id=417or/docs/page3. Drop stop words and dates that carry no meaning, keep the depth shallow, and pick one trailing-slash convention and enforce it everywhere. Any path that changes needs a 301 from the old one in the same commit. A live URL changed without a redirect loses every ranking and backlink it had; if you cannot add the redirect, leave the URL alone and report it. - Crawlability:
robots.txtthat blocks nothing needed to render the page and points at the sitemap; an XML sitemap generated from the real route table, with absolute URLs and honestlastmod;noindexon thin, duplicate, and internal pages; a 404 that returns status 404 rather than a 200 with an error in the body. Confirm no stagingnoindexorDisallow: /can reach production — that single line is the most expensive bug in this skill. - Structured data: JSON-LD matching the page —
OrganizationandWebSiteon the home page,Articlewith author and dates,BreadcrumbList,SoftwareApplication,Product. Mark up only what is visibly on the page; invented ratings or prices earn a manual penalty, not a rich result. Google retires rich-result types —HowToin 2023,FAQPagein 2026 — so check its search gallery before promising one, and don't add markup only for a result Google no longer shows. Validate the syntax before you finish. - Images: every image that carries meaning gets
altdescribing what it shows or does in context — a button's action, a screenshot's content, a chart's takeaway. Decorative images getalt="", never a missing attribute. Don't open with "image of", don't stuff terms. While you are there: descriptive file names, explicitwidthandheightto stop layout shift,loading="lazy"below the fold but never on the LCP image, and modern formats withsrcset. - Links, both directions:
- Internal — descriptive anchor text over "click here" and "read more"; no orphan pages; related pages cross-linked; every internal link resolving.
- Outbound — where the copy makes a claim, link the primary source.
Linking to authoritative pages is a quality signal, not a leak. Mark paid
or untrusted links
rel="sponsored"orrel="ugc", and verify each external URL still resolves. - Inbound — you cannot create backlinks from inside a repository, and
any skill that claims otherwise is describing a link scheme. What you can
do is make the project linkable and consistent: correct
homepageandrepositoryfields in the package manifest, the repository's own description, topics, and website field, one canonical domain everywhere it is cited, and no broken URL on a page that others already link to. Then list legitimate outreach targets for the operator — registries the project belongs in, "awesome" lists, docs of tools it integrates with, its own changelog and release notes.
- Core Web Vitals, to the extent the repo controls them: render-blocking CSS and JS, font loading and fallbacks, a preloaded LCP image, and reserved space for anything that arrives late.
- Validate: rebuild, rerun the project's link check and Lighthouse or equivalent if it has one, and re-read the built output. Confirm the counts from step 1 are now zero, that the sitemap matches the routes the build emitted, and that every redirect you added resolves to a 200.
In plan mode, stop after step 1; if the build cannot run without writes, read the templates instead and say so. The plan is the Pages table with each proposed title and description, every URL change with its redirect, and the site-wide changes.
Constraints
- Never change a published URL without a 301 in the same change.
- No manipulation: no keyword stuffing, hidden text, cloaking, doorway pages, bought or exchanged links, or structured data describing things not on the page. All of it is detectable, all of it is penalised, and none of it is yours to gamble with.
- Alt text is for the reader who cannot see the image. Search benefit is a side effect of writing it honestly.
- Metadata, markup, and links are in scope. Rewriting the project's actual copy is a voice decision — propose it, don't do it unasked.
- Don't add analytics, tag managers, consent banners, or any third-party script. That is a privacy and performance decision for the operator.
- Fetching an external URL to check it resolves is fine. Submitting a sitemap, registering a property, pinging a search engine, or posting anywhere is not.
- Don't guess the production domain, brand name, or company details. Ask.
- Report what you inspected and what you did not. Never report "SEO complete".
Done when
The build passes, every indexable page has a unique title, description,
canonical, single h1, and social image, every img has a resolved alt
decision, the sitemap and robots.txt agree with the real routes, every
internal link and every redirect resolves, and each page has a stated target
query in the report.
Output
Open with one line: how many pages were audited, how many changed, and whether any URL changed.
Pages
| URL | Primary term | Title | Fixed |
Fixed is a short list of what changed on that page (title, description,
canonical, h1, alt×4, jsonld).
URL changes
| Old | New | Redirect |
Omit the table when nothing moved.
Site-wide — one line each for robots.txt, the sitemap, structured data,
redirects, and anything under step 10, as path plus what changed.
Close with three short lists:
- Outreach — where this project could legitimately be linked from, and why it qualifies. Suggestions for the operator, never actions taken.
- Left alone — pages, URLs, or images you did not touch, and what would settle each. Missing alt text you could not write because the image's meaning was unclear belongs here, named.
- Needs a human — copy rewrites, domain decisions, a Search Console submission, or anything requiring access you do not have.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
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.

