Comparison
cms-lab sits between CMS data and rendered routes. It does not replace link checkers, browser tests, Lighthouse, accessibility tools, or production monitoring.
Short version
Most mature tools operate on URLs or pages. cms-lab starts from CMS documents, resolves the routes your app expects, probes those routes, and adds content diagnostics around fields, SEO, images, statuses, and report output.
Where it overlaps
| Tool | Strong at | CMS-aware gap | Use together |
|---|---|---|---|
| lychee / linkinator | Finding broken links across URLs, Markdown, HTML, or crawled pages. | They do not know which CMS document produced a route, which field is required, or whether SEO/image fields are complete before rendering. | Use them for broad link coverage; use cms-lab for CMS document-to-route checks and content diagnostics. |
| Playwright | Browser flows, login paths, visual assertions, network checks, and project-specific smoke tests. | A CMS crawl has to be custom-built: fetch content, map routes, handle statuses, summarize diagnostics, and maintain reports. | Use Playwright for critical user journeys; use cms-lab for repeatable CMS content sweeps. |
| Lighthouse CI | Performance budgets, page-quality audits, accessibility signals, SEO signals, and CI gating for rendered pages. | It audits pages, not the CMS inventory behind them. It will not tell you that a content type has no route mapping or that a draft-like item is reachable. | Use Lighthouse CI for page quality; use cms-lab to choose and explain the CMS-driven pages that need checking. |
| next-sitemap + curl | Simple reachability checks for URLs that are already in a sitemap or route list. | It usually misses orphaned CMS entries, required field rules, provider statuses, image alt fields, and adapter-specific normalization. | Use curl loops for quick uptime checks; use cms-lab when the source of truth is CMS content. |
When cms-lab is a good fit
- Your CMS has many entries and only some should map to public routes.
- Route construction depends on CMS fields, relations, locale prefixes, or project-specific helper functions.
- Missing SEO fields, required fields, or image alt text should be visible before deploy.
- You want one local report that links diagnostics back to content type, path, and source document.
When another tool is better
- Use Playwright when the problem is user interaction, auth, checkout, browser state, or visual behavior.
- Use Lighthouse CI when the problem is performance, accessibility audit scoring, or rendered-page quality budgets.
- Use a link checker when the problem is broad link coverage across a site or documentation corpus.
- Use CMS-native validation when editors should be blocked before saving a bad entry.
Common setup
In mature projects, these tools usually complement each other instead of replacing each other.
npx @cms-lab/cli scan --ci --report npx playwright test npx lhci autorun
Next steps: scan command, CI setup, diagnostic codes, and bug examples.