When to use it
You run several small sites (Astro, Next static export, Hugo…) and want the same SEO hygiene applied everywhere without babysitting each one. This is the swarm we run most often.
Swarm layout
| Role | Runs in | Does |
|---|---|---|
| Coordinator | the folder that contains all site repos | Lists the sites, writes one brief per site, starts the fixer sessions, collects their reports into one summary |
| Fixer (×N) | its own git worktree of one site | Audits, fixes, builds, opens a PR, reports back |
One fixer per site, never two on the same repo. Fixers never merge or deploy; a human does.
The fixer brief
Task: SEO audit and fix for <SITE> (repo: <PATH>, live URL: <URL>).
Work in your own git worktree and branch. Do not touch other repositories.
1. Audit, and write the findings to docs/seo-audit-<DATE>.md:
- titles and meta descriptions: missing, duplicated, too long
- canonical URLs: present, absolute, pointing at the live domain (not *.pages.dev)
- sitemap.xml and robots.txt: present, reachable, listing only live pages
- broken internal links and 404s in the build output
- structured data (Organization / Article / FAQ) that matches visible content
- Open Graph tags, image alt text, heading order (one H1)
2. Fix what is safe to fix in code. Do not rewrite copy beyond titles and descriptions.
3. Build. The build must pass with zero new warnings.
4. Commit, push the branch, open a pull request with the audit summary in the body.
5. Report: PR link, what you fixed, what you left for a human and why.
Never merge, deploy, change DNS or touch analytics settings.
Approval rules (SoloSwarm config.json)
The built-in rules already hold git push, gh pr merge and deploys for approval. If you trust fixers to push their own branches, allow just that:
{
"rules": [
{ "id": "allow-branch-push", "risk": "medium", "description": "Fixers may push claude/* branches",
"tool": "^Bash$", "command": "git push( -u)? origin claude/" }
]
}
Merges and deploys still wait for you.
Budget
Set a project budget per site (for example $10/day). A fixer that loops on a failing build hits the budget and stops instead of burning the night.
Done when
- Every site has an audit file and a PR, or a clear “nothing to fix”
- Every PR builds in CI
- The coordinator’s summary lists what needs a human (copy decisions, DNS, analytics)
Lessons from real runs
- Canonicals pointing at the preview domain are the most common finding. Check the configured
siteURL first. - The live site may not be what’s on main. A fixer should check the hosting provider’s latest production deployment before assuming the repo is live.
- Keep reports short and structured; the coordinator reads 20 of them.