mcpField
R
rendering-strategies

rendering-strategies

github.com/kostja94Marketing & growth1.1k975 installsUpdated 2d ago
Repository

About rendering-strategies

A technical SEO skill for teams choosing rendering strategies to improve visibility to search engines and AI crawlers. It covers rendering methods, crawler behavior, and checks for content in initial HTML.

Key features

  1. 01Compare SSG, SSR, ISR, and CSR
  2. 02Choose rendering by page type
  3. 03Explain search and AI crawler behavior
  4. 04Check component content in initial HTML
  5. 05Structure setup reviews and recommendations

Use cases

  1. 01Select rendering for blogs and docs
  2. 02Assess SEO for dynamic pages
  3. 03Check whether tabs and navigation are crawlable

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/kostja94/marketing-skills --skill rendering-strategies

After installing, type/rendering-strategiesin Claude Code to confirm it loaded.

Details

From the project README

SEO Technical: Rendering Strategies

Guides rendering strategy selection and optimization for search engine and AI crawler visibility. Golden rule: Page data and metadata must be available on page load without JavaScript execution for optimal SEO.

When invoking: On first use, if helpful, open with 1–2 sentences on what this skill covers and why it matters, then provide the main output. On subsequent use or when the user asks to skip, go directly to the main output.

Scope (Technical SEO)

  • Static vs dynamic: SSG, SSR, ISR, CSR; when to use each
  • Crawler behavior: Googlebot renders JS (with delays); AI crawlers do not
  • Component-level: Content in initial HTML; tabs, carousels, nav
  • Dynamic rendering: Prerender for bots when full SSR/SSG is not feasible

Rendering Methods

MethodWhen HTML generatedSEOBest for
SSG (Static Site Generation)Build time✅ BestBlog, docs, marketing pages; content rarely changes
SSR (Server-Side Rendering)Request time✅ GoodNews, product pages; dynamic, personalized content
ISR (Incremental Static Regeneration)Build + revalidate✅ GoodLarge sites; static with periodic updates
CSR (Client-Side Rendering)Browser (after JS)❌ PoorDashboards, account pages; no SEO needed
Dynamic renderingOn-demand for bots✅ FallbackSPAs; prerender for crawlers, SPA for users
SSG (Static Site Generation)

HTML generated at build time; same HTML for every request. Best for SEO: crawlers receive full HTML immediately; optimal performance.

  • Use when: Blog, docs, marketing pages, content that doesn't change frequently
  • Framework: Next.js getStaticProps, Astro, Gatsby
SSR (Server-Side Rendering)

HTML generated on each request. Good for SEO: crawlers receive complete HTML; supports dynamic, personalized content.

  • Use when: News, product pages, user-specific content
  • Tradeoff: Higher server load; slower TTFB than SSG
  • Framework: Next.js getServerSideProps, Remix
ISR (Incremental Static Regeneration)

Static at build; pages can revalidate after a period. Good for SEO: combines static performance with freshness.

  • Use when: Large sites (millions of pages); content updates periodically
  • Framework: Next.js revalidate in getStaticProps
CSR (Client-Side Rendering)

Server sends minimal HTML shell; content renders in browser after JS loads. Not for SEO: crawlers may see empty content; indexing delays or failures.

  • Use when: Dashboards, account pages, internal tools—no search visibility needed
  • Avoid for: Public content, marketing pages, blog
Dynamic Rendering

Serve prerendered HTML to crawlers; serve SPA to users. Fallback when full SSR/SSG is not feasible (e.g. legacy SPA migration).

  • How: Detect crawler user-agent; route to prerender service (e.g. Prerender.io) or headless render
  • When: JavaScript-heavy sites; migration period; product/docs with CSR
  • Note: Google permits this; prerendered content should match user experience

Crawler Behavior

CrawlerJavaScriptContent in initial HTML
GooglebotRenders JS (Chrome); may have multi-day queueFull weight; SSR/SSG preferred
AI crawlers (GPTBot, ClaudeBot, PerplexityBot)Do not execute JSRequired—CSR content invisible
BingbotRenders JSSame as Googlebot

AI crawlers: ~28% of Googlebot's crawl volume. Critical content (articles, meta, nav) must be in initial HTML. See site-crawlability for AI crawler optimization; generative-engine-optimization for GEO.

Component-Level: Content in Initial HTML

Google does not simulate user clicks (tabs, carousels, "Load more"). Content loaded via AJAX or on interaction is not discoverable.

ComponentRequirementImplementation
Tabs / AccordionAll tab content in DOM at loadServer-render; use <details>/<summary> or CSS show/hide
CarouselAll slides in initial HTMLServer-render; CSS/JS for show/hide only
HeroHeadline, CTA, LCP image in HTMLNo JS-only rendering
NavigationAll nav links in first paintNo JS-injected menus for critical links

Recommendation: Server-render (SSR/SSG) all critical content; use JS only for interaction (show/hide, animation). Content loaded on click = not indexed.

Decision Guide

Content typeRenderingReason
Blog, docs, marketingSSG or ISRBest SEO; fast; static
Product, news, dynamicSSRFresh content; crawler-ready
Dashboard, accountCSRNo SEO; auth required
Legacy SPADynamic renderingBridge until SSR/SSG migration

Output Format

  • Current setup: SSG, SSR, CSR, or hybrid
  • Recommendation: By page type
  • Component checks: Tabs, carousel, nav—content in initial HTML?
  • References: Next.js Rendering, Vercel SSR vs SSG

Related Skills

  • site-crawlability: AI crawler optimization; SSR for critical content; URL management
  • generative-engine-optimization: GEO; AI crawlers don't execute JS
  • core-web-vitals: LCP; SSR/SSG for above-fold; client-side hurts LCP
  • mobile-friendly: Mobile-first indexing; content parity
  • tab-accordion: Content in DOM at load; server-render tabs
  • carousel: Content in initial HTML; server-render slides
  • hero-generator: Hero in initial HTML; avoid JS-only
  • navigation-menu-generator: Nav in first paint; no JS-only menus

Comments

Markdown supported