SOLIDJS SEO AUDIT · SOLIDSTART SSR · @SOLIDJS/META · AI VISIBILITY

Free SolidJS SEO Audit

Plain SolidJS renders client-side — Googlebot sees an empty shell on the first crawl. SolidStart adds SSR and SSG capabilities that fix this. DeepSEOAnalysis audits SolidJS and SolidStart sites, detecting rendering gaps, @solidjs/meta coverage, sitemap configuration, and AI visibility signals.

Audit my SolidJS site →How we score

WHAT WE CHECK

6 SolidJS-specific SEO checks

Beyond the 80+ general checks, the engine detects SolidJS CSR rendering gaps, checks @solidjs/meta server-side metadata injection, evaluates URL structure for keyword slugs vs IDs, and audits AI visibility signals — with SolidStart component names and API routes for each fix.

⚙️

SSR vs CSR rendering detection

Plain SolidJS renders entirely client-side — the server returns `<div id="root"></div>` and SolidJS\'s reactive runtime mounts the component tree in the browser. Googlebot sees the empty shell on first-wave crawl and must wait for a second-wave JavaScript render that can be delayed by days or weeks. SolidStart with SSR enabled sends the full HTML on the first HTTP response, including all content and metadata. SolidStart also supports SSG (static site generation) via the `solid-start-ssg` adapter, which pre-renders pages at build time for deployment as static files. The audit detects the rendering mode by comparing the server-returned HTML (the first-wave view) against the fully rendered DOM. If headings, body text, or JSON-LD are absent from the raw HTML response but present after JavaScript execution, the page is flagged as CSR-affected with SolidStart migration guidance.

🏷️

Metadata coverage with @solidjs/meta

SolidStart uses `@solidjs/meta` for head tag management. The `<Title>`, `<Meta>`, `<Link>`, and `<Script>` components write into the document head during SSR — they\'re rendered server-side and injected into the HTML response. A proper SolidStart metadata setup in a route component: `<Title>Page Title | Site Name</Title>`, `<Meta name="description" content="..." />`, `<Link rel="canonical" href="https://example.com/page/" />`, and a `<Script type="application/ld+json">{JSON.stringify(schema)}</Script>` for structured data. The critical requirement: `@solidjs/meta` must be configured to work with SolidStart\'s SSR — it renders server-side when used within SolidStart\'s SSR context. Common failure: using `document.title = ...` or `document.querySelector(\'meta[name=description]\')` DOM manipulation (client-only, not in server-rendered HTML). The audit checks every crawled page for title, meta description, and canonical presence in the server-rendered HTML.

🔗

SolidStart router URL structure

SolidStart uses file-based routing: `src/routes/blog/[slug].tsx` creates a route at `/blog/:slug`. Route parameters use brackets in file names — `[slug]` for keyword-based slugs (SEO-friendly), `[id]` for numeric IDs (not SEO-friendly unless slugified). SolidStart also supports nested layouts via `(layout)` directories and catch-all routes with `[...path].tsx`. The main URL structure consideration for SEO: use keyword slugs in dynamic routes (`[slug]`) rather than numeric IDs (`[id]`). For database-driven content, ensure the data source returns a slug field and use it in the URL. URL segments should use lowercase, hyphen-separated keywords (`/blog/my-article-title` rather than `/blog/MyArticleTitle`). The audit checks URL patterns across all crawled pages and flags numeric-ID URL patterns as on-page issues.

🗺️

Sitemap generation

SolidStart provides no built-in sitemap generation. The most direct approach for dynamic content: a custom SolidStart API route at `src/routes/sitemap.xml.ts` that returns an XML sitemap generated from the content data source. This route runs on the server (SSR), queries the database or CMS, and streams the XML response with `Content-Type: application/xml`. For static sites generated with `solid-start-ssg`: a build-time script that reads the static route list and generates `sitemap.xml` before the static site is deployed. The sitemap should include all indexable pages, use absolute URLs, include accurate `lastmod` timestamps from the content data, and be referenced by a `Sitemap:` directive in `robots.txt`. The audit checks sitemap presence at `/sitemap.xml`, URL count vs crawled page count, `lastmod` recency, and the `Sitemap:` directive.

🤖

robots.txt and AI crawler access

In SolidStart projects, `robots.txt` can be served as a static file from the `public/` directory (maps to `/robots.txt`) or as a dynamic API route at `src/routes/robots.txt.ts`. For most sites, `public/robots.txt` is the simpler approach — it\'s committed to the repo and served by the underlying Vite/Nitro server. Common gaps: `robots.txt` is missing entirely; AI crawlers (GPTBot, ClaudeBot, PerplexityBot, Applebot-Extended) are blocked by an overly broad `Disallow: /` or by SolidStart admin/API routes that use a broad disallow pattern; the `Sitemap:` directive is absent; development or admin routes (`/admin`, `/_build`, `/api/`) are not disallowed. The audit checks the file at `/robots.txt`, all AI crawler user-agents, and common SolidStart development route patterns.

🧠

AI visibility for SolidStart sites

Serve `llms.txt` from SolidStart\'s `public/` directory — `public/llms.txt` maps to `/llms.txt` via static file serving. FAQPage JSON-LD: use `<Script type="application/ld+json">{JSON.stringify(faqSchema)}</Script>` within a SolidStart route component using `@solidjs/meta` — this renders the JSON-LD server-side into the HTML response. For route-specific structured data, define the schema object in the route\'s server-side data function (createRouteData or loader) and pass it to the template. The audit checks all five AI visibility signals — llms.txt presence, AI crawler access, FAQPage/HowTo schema in server-rendered HTML, question-heading ratio (≥20%), and content chunkability (avg section ≤400w) — with SolidStart-specific component and API names for each fix.

HOW IT WORKS

Audit your SolidJS site in 60 seconds

  1. Enter your SolidJS or SolidStart site URL. Works with plain SolidJS, SolidStart (SSR and SSG), VinXI, and any deployment target (Netlify, Vercel, Cloudflare Workers, Node.js). No access to source code or build config needed.
  2. We crawl and analyse. The engine detects the rendering mode (CSR vs SSR vs SSG), compares server-rendered HTML against the full DOM for content and metadata gaps, checks URL structure, validates JSON-LD in the server-rendered HTML, tests sitemap and robots.txt, measures CrUX Core Web Vitals, and evaluates all five AI visibility signals.
  3. You get a prioritised report. SolidJS-specific issues first — rendering mode, @solidjs/meta coverage, URL structure, sitemap configuration, AI crawler access — then general SEO, each with SolidStart component names, package references, and code patterns for the fix.

FAQ

Questions about the SolidJS SEO audit

Does SolidJS have SEO problems?

Plain SolidJS (without SolidStart) renders client-side: the server sends an HTML shell and the browser executes the reactive JavaScript to mount the component tree. Googlebot sees only the shell on first-wave crawl — no content, no metadata. SolidStart (the SolidJS meta-framework, analogous to Next.js for React or Nuxt for Vue) adds SSR and SSG capabilities, delivering full HTML to Googlebot on the first HTTP response. For SEO, SolidStart with SSR or SSG is required; plain SolidJS has the same rendering gap problem as other CSR frameworks.

How does SolidStart handle metadata for SEO?

SolidStart uses the `<Meta>` and `<Title>` components from `@solidjs/meta` (built on `@solidjs/meta`, formerly `solid-meta`) for head tag management. These are rendered server-side during SSR, injecting `title` and `meta` tags into the HTML before it\'s sent to the browser — avoiding the client-only metadata problem. In SolidStart with SSR: `<Title>My Page</Title>` and `<Meta name="description" content="..." />` in any route component render the correct metadata server-side. A custom `<MetaProvider>` wraps the app in `root.tsx` or `app.tsx`. The audit checks whether metadata is present in the server-rendered HTML (before JavaScript execution) for every crawled page.

How do I add a sitemap to a SolidStart site?

SolidStart has no built-in sitemap generation. The options: (1) A custom API route in SolidStart (`src/routes/sitemap.xml.ts`) that returns XML with your site\'s URLs — most flexible for dynamic content. (2) The `solid-start-sitemap` community package (check npm for current status and compatibility with your SolidStart version). (3) Generating a static `sitemap.xml` at build time via a Vite plugin or a custom build script that queries your content source. The sitemap must be hosted at `/sitemap.xml` on the same domain as the site, with a `Sitemap:` directive in `robots.txt`.

Is the SolidJS SEO audit free?

Yes. The complete audit is free with no signup and no email gate. Paid plans add saved history, scheduled monitoring, larger crawls (up to 1,000 pages), and agency workflows.