# seo-ops: SEO foundation checks packaged as an Agent Skill

> seo-ops is a repository of three things: a set of 26 structural SEO and GEO checks, a Python checker that fetches a site like a crawler and reports pass or fail with evidence, and a content supply checklist for the team that writes the pages. It runs inside Claude Code or Codex, and there is no language model in the check itself.

**tigerless-labs/seo-ops** — SEO foundation checks as an Agent Skill: give it a URL, get a crawler's-eye pass/fail report with evidence. 26 structural checks, zero LLM, deterministic.

- Repository: https://github.com/tigerless-labs/seo-ops
- Stars: 879 · Forks: 38
- Language: Python
- License: not declared
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/tigerless-labs-seo-ops

## A report instead of an opinion

seo-ops is described as SEO foundation checks as an Agent Skill, and the framing is precise: it checks a site's SEO foundation, meaning the machine-readable structure that search engines and AI retrieval need in order to fetch, read, index and cite the site.

The input is deliberately minimal. The only required input is a URL, and the checker fetches the site the way a crawler would. There is no code access and no framework integration. The output is a pass or fail report with evidence.

What makes this different from asking an assistant to review your site is stated plainly in the repository description: zero LLM, deterministic. The checking itself is a script that reads the live HTTP and HTML output and applies a fixed set of rules. Whatever model ends up reading the report and explaining it to you, the pass or fail result is the same every time for the same site.

That distinction is the whole design. A language model asked to audit a site will produce a different set of findings on different runs, and its severity judgements will shift with phrasing. Here the judgement is a rule evaluation, and the agent's job is narrowed to confirming the target, running the script, reading the report and explaining the failures.

The stack is Python 3.9 or newer on Linux or macOS, the repository has no releases, the licence is listed as unknown, and the last push was on 2026-09-01.

## The C set: 26 checks with their own reference pages

The bulk of the repository is the checklist file, references/checklist/checklist.md, which holds what the project calls the C set: 26 SEO and GEO structural checks, split into site-level checks, checks that apply per indexed page, and conditional checks.

That three-way split is the structure to understand before you read any individual result. A site-level check is a property of the whole domain, such as how the site responds to a crawler. A per indexed page check is a property of each page, so a single bad template produces a failure across every page that uses it. A conditional check applies only in some circumstances, and skipping it because the condition does not hold is a correct outcome rather than a missing check.

The other thing to notice is the depth of the supporting documentation. Each check has a detailed document of its own at references/checklist/references/C<N>.md, and each of those documents carries criteria, common mistakes and authoritative references. That is the difference between a checklist and a rubric: the checklist tells you a rule, the reference page tells you why the rule exists and what a wrong answer looks like.

The report itself is a separate artefact, and the repository links an example report file, references/report.example.md, so you can see the output format before you run anything.

For an agent-driven workflow, these reference pages are what make the run useful. The agent is instructed to read the report and explain each red item by severity, and the severity levels it uses are P0, P1 and P2. The reference pages are what let it explain the fix rather than just restate the failure.

## Why it reads HTTP output instead of your source

The checker script, scripts/run.py, has one architectural rule that everything else follows from: zero LLM, and no frontend-framework dependency, because it only reads the live HTTP and HTML output.

The consequence is spelled out in the documentation. React, Vue, Next, WordPress and plain static sites all test the same way. A site built with any of them produces the same HTTP responses for a crawler, and the checks are written against those responses rather than against templates or source files.

That is a deliberate narrowing. The tool can be pointed at any site on the internet, including one you do not own, and it works the same for a client site, a competitor audit or a staging environment. There is nothing to install in the application and no framework plugin to keep in step with.

The cost is the same narrowing seen from the other side. A crawler sees rendered output for the pages it fetches, so a fault in a template shows up as a fault on the pages that use it, not as a single diagnosable error in the source. And because the check is per indexed page, the coverage depends on which URLs the checker visits, which is a sampling question the report has to answer rather than something the script can fix.

That is also why the agent asks you to confirm live site versus code review before it runs. The repository describes the agent introducing the checks, confirming live site vs code review, running, and then explaining the red items. Live fetching is what the script does; a code review is what a person or an agent does with the source, and the skill makes you choose which mode you are in.

## The T set: a brief for the people who write the pages

The third piece of the repository is references/content/content-checklist.md, called the T set. It is described as a supply checklist for the site's content design team: which inputs SEO needs content to provide, and each item annotated with the downstream C checks it feeds.

The inputs it names are ordinary editorial and design decisions: title and description, the H2 outline, image alt text, ymyl judgment, and Open Graph copy. The annotation is the interesting part, because it turns a checklist into a contract. Each content input is tied to the specific structural checks it influences, so the content team can see which of the 26 checks their work feeds rather than guessing.

That split between the two sets is a reasonable way to organise an SEO audit. The C set is mechanical and belongs to whoever owns the templates and the server configuration. The T set is editorial and belongs to whoever writes and designs the pages. Handing both groups one mixed list of findings is how audits end up being ignored; handing each group the findings it can act on, plus the link between them, is how they get fixed.

The details for each T item live in references/content/references/T<N>.md, following the same pattern as the C references.

It is worth being clear about what this is not. The T set is a supply checklist, not a grader. It tells the content team what to hand over; it does not score their work, and the repository does not describe any mechanism for automated judgement of content quality.

## Installing it as a skill in Claude Code or Codex

The whole repository is an Agent Skill, so installation is a matter of telling your agent where to get it. The README's instruction is short: install https://github.com/tigerless-labs/seo-ops as a skill.

There is also a plugin path, and it differs between the two agents in an important way.

For Claude Code the commands go in the Claude Code input box, not in a shell:

```bash
/plugin marketplace add tigerless-labs/seo-ops
/plugin install seo-ops@seo-ops
```

For Codex the commands go in the terminal:

```bash
codex plugin marketplace add tigerless-labs/seo-ops
codex plugin add seo-ops@seo-ops
```

The distinction is not cosmetic, because people copy these into the wrong place and then conclude the tool is broken.

Two operational details are documented. If the skill does not show up, start a new session. And updating follows the same split: for Claude Code you re-run the install command, which refreshes the marketplace first, and for Codex you run a marketplace upgrade followed by the plugin add.

The repository structure supports both paths, with .claude-plugin/ and .codex-plugin/ directories at the root alongside .agents/, plus a skills/ directory, the SKILL.md file that carries the usage details, the references directory and the scripts directory.

Once installed, the trigger is a slash command, or a description of the task:

```bash
/seo-ops check example.com
```

The agent then introduces the checks, confirms whether you want a live site check or a code review, runs the script, and explains the red items by severity.

## No releases, no stated licence, one push in September

The repository is small and its top-level entries are .agents, .claude-plugin, .codex-plugin, .github, .gitignore, the README, SKILL.md, redlines.md, references, scripts and skills.

That redlines.md file at the root is worth a note, because its name implies a list of things the checker will not do. For a tool that automates judgement about a website, the boundaries are as important as the checks, and a project that ships its redlines in the repository is telling you where it refuses to go.

The maintenance record is modest. There are no GitHub releases, so there is nothing to install as a version and no changelog to diff against. The last push was on 2026-09-01, which is inside the six month window in which the project can be described as receiving work, but there is no tag to point at.

The licence is the other loose end. It is listed as unknown and there is no licence file among the top-level entries. For a repository you install into an agent session and point at your own website, that may not matter to you. For a consultancy that wants to run it across client sites and offer the report as a service, it does, and the question to settle is with the authors rather than inferred from the repository. This is a note on what the repository does and does not state, not legal advice.

The project is credited to Tigerless, with tigerless.ai and tigerless.com linked at the bottom of the README, so there is an organisation behind it rather than an anonymous account, which is the first thing to check when a licence question comes up.

## Conclusion

seo-ops suits a team that has a website, suspects its technical SEO foundation is weak and wants a repeatable report rather than an opinion, and it suits teams already working with Claude Code or Codex who want the check to run inside their agent session. It is the wrong choice if you need content quality judgement, because the checks are structural and the content side is a checklist rather than a grader, and it is the wrong choice if you cannot expose a public URL, since the only required input is a URL the checker fetches. Verify three things before you trust the output: that the 26 checks match the failures you are actually seeing, that the sampled pages include the templates that matter rather than a handful of indexable pages, and whether the licence position is acceptable to you, because the repository does not state one.

## FAQ

### What is seo-ops?

It is an Agent Skill that checks a site's SEO foundation, meaning the machine-readable structure that search engines and AI retrieval need to fetch, read, index and cite. The only required input is a URL, and the output is a pass or fail report with evidence.

### How many checks does seo-ops run, and how are they organised?

There are 26 structural SEO and GEO checks in the C set, split into site-level checks, checks per indexed page and conditional checks. Each check has its own reference document with criteria, common mistakes and authoritative references.

### Does seo-ops use a language model to decide the results?

No. The repository describes the checker as zero LLM and deterministic, with no frontend-framework dependency, because it only reads the live HTTP and HTML output. React, Vue, Next, WordPress and plain static sites therefore all test the same way.

### How do I install seo-ops in Claude Code or Codex?

For Claude Code run /plugin marketplace add tigerless-labs/seo-ops and /plugin install seo-ops@seo-ops in the Claude Code input box. For Codex run codex plugin marketplace add tigerless-labs/seo-ops and codex plugin add seo-ops@seo-ops in the terminal. You can also just ask your agent to install https://github.com/tigerless-labs/seo-ops as a skill.

### How do I run a check with seo-ops?

Once installed, type /seo-ops check example.com in the agent's input box, or describe the task and it triggers the same way. The agent introduces the checks, confirms live site versus code review, runs the script and explains the red items by severity as P0, P1 or P2.

### What is the T set in seo-ops?

It is a supply checklist for the site's content design team, covering the inputs SEO needs content to provide, such as title and description, H2 outline, image alt, ymyl judgment and Open Graph copy. Each item is annotated with the downstream C checks it feeds.

## Sources

- [Issues](https://github.com/tigerless-labs/seo-ops/issues)
- [README](https://github.com/tigerless-labs/seo-ops/blob/main/README.md)
- [tigerless-labs/seo-ops on GitHub](https://github.com/tigerless-labs/seo-ops)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/tigerless-labs-seo-ops