
Diagnose Seo
Run a structured technical SEO troubleshoot when crawl, index, robots, canonical, sitemap, or rendering issues block search visibility.
Overview
Diagnose SEO is an agent skill most often used in Launch (also Operate, Grow) that runs a four-layer crawl → index → render → signals framework for technical SEO troubleshooting.
Install
npx skills add https://github.com/calm-north/seojuice-skills --skill diagnose-seoWhat is this skill?
- Four-layer diagnostic order: crawlability, indexability, renderability, then signals
- robots.txt review including user-agent rules, staging Disallow traps, and Sitemap directives
- Canonical, sitemap, and indexation checks with ordered troubleshooting steps
- Rendering and JS/CSS blockers called out when Googlebot cannot see full content
- Explicit boundary: page speed and Core Web Vitals belong to audit-speed, not this skill
- Four diagnostic layers ordered: crawlability, indexability, renderability, signals
- Metadata version 1.0.0 documented in skill frontmatter
Adoption & trust: 2.1k installs on skills.sh; 10 GitHub stars; 2/3 security scanners passed (skills.sh audits).
What problem does it solve?
You shipped pages but search consoles show crawl anomalies, missing indexation, or conflicting canonicals and you lack an ordered checklist to isolate the root cause.
Who is it for?
Solo builders debugging why specific URLs are excluded, blocked, or inconsistently indexed after launch or site migrations.
Skip if: Core Web Vitals, Lighthouse scores, or page-speed optimization—this skill explicitly defers those to audit-speed.
When should I use this skill?
User asks about crawl issues, indexation, robots.txt, canonical errors, sitemap problems, rendering failures, or general technical SEO troubleshooting—not Core Web Vitals speed.
What do I get? / Deliverables
You get a layer-by-layer diagnostic path with robots, sitemap, canonical, and rendering checks so you can fix access and indexation before tuning on-page SEO.
- Ordered diagnostic findings across crawl, index, render, and signal layers
- Actionable fixes for robots, canonical, and sitemap misconfigurations
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Technical SEO diagnostics are canonically filed under Launch because indexation and crawl health determine whether shipped pages can rank and be discovered. SEO subphase covers indexation, crawl access, and on-page technical signals—not Core Web Vitals speed audits (use audit-speed for that).
Where it fits
Post-launch Search Console shows “Discovered – currently not indexed” and you need robots and canonical checks before rewriting copy.
After a deploy, crawl stats drop and you verify sitemap URLs and disallow rules did not regress from staging.
Organic landing pages lose impressions and you distinguish indexation loss from ranking/content issues using the four-layer order.
Pre-release checklist confirms production robots.txt is not still Disallow: / from staging.
How it compares
Use as a structured troubleshooting runbook instead of ad-hoc “ask the agent to guess” technical SEO chat.
Common Questions / FAQ
Who is diagnose-seo for?
Indie founders, marketers-with-code, and agents supporting content sites, SaaS marketing pages, or ecommerce catalogs who need crawl and indexation diagnostics without hiring an SEO agency.
When should I use diagnose-seo?
Use at Launch when pages are not indexing after go-live; in Operate when crawl errors spike post-deploy; in Grow when organic traffic drops because sitemaps or canonicals drifted—always before rewriting content for ranking.
Is diagnose-seo safe to install?
Review the Security Audits panel on this Prism page for install counts and risk signals; the skill is diagnostic guidance and does not require shell or secrets by default.
SKILL.md
READMESKILL.md - Diagnose Seo
# Diagnose SEO Structured diagnostic framework for crawl issues, canonicalization errors, indexation problems, and rendering failures. ## Diagnostic Approach Technical SEO problems fall into four categories. Diagnose in this order — each layer depends on the previous one working correctly: 1. **Crawlability** — Can search engines find and access the pages? 2. **Indexability** — Are the pages allowed to be indexed? 3. **Renderability** — Can search engines see the full content? 4. **Signals** — Are the right signals (titles, structured data, links) in place? ## Layer 1: Crawlability Check these in order: ### robots.txt - Fetch `[domain]/robots.txt` and review the rules - Look for overly broad `Disallow` rules blocking important paths - Verify `Sitemap:` directive points to the correct sitemap URL - Check for different rules per user-agent (Googlebot vs others) **Common mistakes:** - `Disallow: /` blocking the entire site (often left from staging) - Blocking CSS/JS files that Googlebot needs for rendering - Blocking API or AJAX endpoints that load dynamic content - Staging robots.txt accidentally deployed to production ### XML Sitemap - Fetch the sitemap URL(s) and check: - Does it return 200? Is it valid XML? - Does it list all important pages? - Does it exclude pages that shouldn't be indexed (404s, redirects, noindex pages)? - Are `<lastmod>` dates accurate and recent? - For large sites: is there a sitemap index? ### Site Architecture - Pages should be reachable within 3 clicks from the homepage - Check for orphan pages (no internal links pointing to them) - Check for redirect chains (page A → B → C — should be A → C) - Check for redirect loops ### Server Response - Do all important pages return HTTP 200? - Check for unexpected 301/302 redirects - Check for soft 404s (page returns 200 but shows "not found" content) - Verify HTTPS is enforced (HTTP should 301 to HTTPS) ## Layer 2: Indexability ### Meta Robots / X-Robots-Tag - Check for `<meta name="robots" content="noindex">` on pages that should be indexed - Check HTTP headers for `X-Robots-Tag: noindex` - Common cause: CMS accidentally applying noindex to pagination, tag pages, or new pages ### Canonical Tags - Every page should have a `<link rel="canonical">` pointing to itself (self-referencing canonical) - Check for canonical tags pointing to wrong pages (common in paginated content, filtered URLs) - Check for conflicting signals: canonical says page A, but noindex is set, or the page redirects **Canonical diagnosis checklist:** - [ ] Does the canonical URL match the actual URL? - [ ] Is the canonical URL accessible (returns 200)? - [ ] Does the canonical URL have the same content? - [ ] Is there only one canonical tag on the page? ### Duplicate Content - Check for the same content accessible at multiple URLs: - With and without trailing slash (`/page` vs `/page/`) - With and without `www` (`example.com` vs `www.example.com`) - HTTP vs HTTPS - URL parameters creating duplicate pages (`?sort=price`, `?page=1`) - Each duplicate set needs one canonical URL; all others should redirect or use canonical tags ## Layer 3: Renderability ### JavaScript Rendering - Does the page content appear in the raw HTML source? Or is it loaded via JavaScript? - If JS-rendered: does Googlebot see the full content? (Use URL Inspection tool in Search Console) - Check for content hidden behind click events, tabs, or accordions - Check for lazy-loaded content that only appears on scroll ### Core Content Visibility - Is the main content in the initial HTML? Or loaded async