알레오 위키wiki
/Rendering
📘Concept⭐️ Pillar

Rendering

최종 업데이트:

Definition

Rendering is the entire process by which web servers and browsers (or bots) process HTML, CSS, and JavaScript to create the final screen users see.

From an SEO perspective, rendering is a core technical element that determines whether search engine bots can recognize page content. The same content may or may not be visible to bots depending on rendering method.

Summary

Rendering selection guide: blog/wiki/landing → SSG. Ecommerce/news → SSR or ISR. SaaS dashboard → SSG for landing, CSR after login. Real-time data → SSR metadata + CSR data. AI bots do not execute JS, so CSR = AEO impossible.

4 Rendering Patterns in Detail

[DIAGRAM: CSR → SSR → SSG → ISR rendering location and timing comparison]

1. CSR (Client-Side Rendering)

Rendering location: Browser (client)
Rendering timing: Real time when user accesses

Flow:

Browser request
→ Server: empty HTML + JS bundle sent
→ Browser: download JS + execute
→ DOM created → screen displayed

HTML source example:

<body>
  <div id="root"><!-- filled by JS --></div>
  <script src="main.abc123.js"></script>
</body>

SEO impact:

  • Googlebot: delayed rendering (two-stage queue)
  • AI bots: mostly cannot recognize
  • Initial TTFB: very fast (small HTML)
  • LCP: slow (content shown after JS execution)

Best for: SaaS dashboards, real-time apps, post-login areas

2. SSR (Server-Side Rendering)

Rendering location: Server
Rendering timing: Real time on each user request

Flow:

Browser request
→ Server: fetch data + complete HTML
→ Send completed HTML to browser
→ Immediate display + JS hydration (interactive)

SEO impact:

  • Googlebot: immediate recognition
  • AI bots: immediate recognition
  • TTFB: may increase by server processing time
  • LCP: fast

Best for: Ecommerce, news media, sites with frequently changing content

Representative frameworks: Next.js (App Router default), Nuxt.js, Remix, SvelteKit

3. SSG (Static Site Generation)

Rendering location: Build server (once at deploy)
Rendering timing: Build time (pre-generated)

Flow:

Run build command
→ Pre-generate HTML for all pages
→ Deploy HTML files to CDN
→
Browser request → serve HTML immediately from CDN

SEO impact:

  • Googlebot: immediate + fastest TTFB
  • AI bots: immediate recognition (best)
  • TTFB: very fast (CDN edge serving)
  • LCP: very fast

Limitation: Content changes require rebuild. Build time issues on sites with millions of pages.

Best for: Blogs, wikis, documentation sites, landing pages

Representative frameworks: Astro, Gatsby, Next.js (Static Export), Eleventy

4. ISR (Incremental Static Regeneration)

Rendering location: Build + server (periodic)
Rendering timing: At build + background regeneration at configured intervals

Flow:

Initial: pre-generate HTML like SSG
→ After configured time: regenerate new HTML in background
→ Refresh CDN cache
→ Subsequent requests: serve new HTML

SEO impact:

  • Retains most SSG advantages
  • Content update reflection time = revalidate setting

Next.js implementation:

// app/page.js
export const revalidate = 3600 // regenerate every hour

// or only specific paths
export async function generateStaticParams() {
  // pre-generate only key pages
}

Best for: Ecommerce (price changes), news (frequent updates), content sites

Googlebot’s Two-Stage Rendering

Google’s officially announced page processing flow:

Stage 1 (immediate): crawl → download HTML → extract links → add to indexing queue
Stage 2 (delayed): rendering queue → execute JavaScript → index rendered DOM

Key point: JS content on CSR pages is processed in stage 2, causing indexing delay. Small sites may take hours; large sites may take days.

See Crawling vs Indexing for details.

AI Bot Rendering

Most AI bots do not execute JavaScript. This is true as of 2026 and is unlikely to change significantly in the near future.

Reasons:

  1. JS execution for bots crawling billions of pages is enormous computing cost
  2. Googlebot uses a two-stage rendering queue because cost is high even for Google
  3. AI bots crawl less frequently than Googlebot and tend to minimize cost

AEO problem with CSR sites:

AI bot request → receives only empty HTML → recognizes no content
→ Site not cited in ChatGPT/Perplexity answers
→ No AEO effect

SSR/SSG is essential in the AI era. See JavaScript SEO for details.

Rendering Selection Guide by Site Type

[COMPARISON_TABLE: Recommended rendering by site type]

Static Content Sites (Blog, Wiki, Documentation)

Recommended: SSG
Reason: Low content change frequency + best SEO/AEO friendliness + low server cost
Example: alleo.wiki (Next.js SSG)

Ecommerce

Recommended: SSR + ISR
Reason: Frequent inventory and price changes + many product pages
Examples: Shopify (SSR), Next.js Commerce

News and Media

Recommended: ISR (SSR for latest articles, SSG for archives)
Reason: Latest articles reflected immediately, archives cached
Examples: Many media sites on Vercel platform

SaaS Marketing Sites

Recommended: SSG (landing pages, blog)
Reason: Marketing content changes infrequently, best Lighthouse scores

SaaS Applications (Post-Login)

Recommended: CSR (post-login dashboard)
Reason: Real-time data, complex interactions, SEO unnecessary (post-login area)

Recommended Hybrid Pattern

example.com (landing page) → SSG
example.com/blog/ → SSG
example.com/app/ (post-login) → CSR
example.com/api/ → API routes

Rendering Performance and Core Web Vitals

Rendering method directly affects Core Web Vitals metrics:

MetricCSRSSRSSG
TTFBFast (small HTML)Medium (server processing)Very fast (CDN)
LCPSlow (after JS execution)FastVery fast
INPMediumMediumFast (less JS)
CLSRisk (dynamic JS insertion)LowVery low

See TTFB and Core Web Vitals for details.

Edge Rendering (2024–2026 Trend)

A new approach that runs SSR at CDN edge to solve traditional SSR drawbacks (server load, regional concentration).

Representative services:

  • Vercel Edge Functions (Next.js)
  • Cloudflare Workers (Remix, SvelteKit)
  • Netlify Edge Functions

Advantages:

  • TTFB close to SSG (edge node serving)
  • SSR dynamic content support
  • Fast response for Korean users (Seoul edge node)

See TTFB for details.

Korea Market Application

Rendering Status in Korean CMS Platforms

  • WordPress: PHP SSR (SEO-friendly by default)
  • Cafe24/Godo Mall: PHP SSR (SEO-friendly by default)
  • Imweb: PHP/Node.js SSR (SEO-friendly)
  • Custom React SPA: Likely CSR → SEO/AEO risk

Common Pattern Among Korean Startups

Many Korean startups adopt pure CSR with React or Vue for fast development. SEO considered later increases migration cost. Using Next.js (SSG/SSR) from the start lowers long-term cost.

Naver Yeti and Rendering

Naver Yeti is known to partially execute JavaScript. However, indexing issues still occur on fully CSR pages. SSR/SSG is advantageous for both Google and Naver.

Frequently Asked Questions

Q. Isn’t SSG unsuitable for sites that update content frequently?
A. ISR solves this. Setting revalidate to 1–60 minutes reflects content changes quickly. On-Demand ISR (cache invalidation on specific events) enables immediate updates.

Q. Will SEO improve immediately when migrating from CSR to SSR?
A. It improves but not instantly. Googlebot takes weeks to months to crawl new SSR HTML and update indexing. AI bots recognize it on the next crawl. Monitor indexing status in GSC after migration.

Q. Which is better for SEO, Gatsby or Next.js SSG?
A. No meaningful SEO difference. Both generate HTML at build time and deploy to CDN. Next.js offers SSG, SSR, and ISR in one framework for higher flexibility. Gatsby has an ecosystem specialized for content-centric sites (blogs, docs).

Q. Can I improve SEO on an SPA without migration?
A. Not a complete fix, but partial improvement is possible: ①Insert key meta tags directly in HTML ②Replace internal links with <a href> tags ③Use services like prerender.io to serve pre-rendered HTML to bots. However, AI bot non-recognition remains unresolved, so SSR/SSG migration should be the long-term goal.

Q. Are serverless and SSR compatible?
A. Yes. SSR works very well in serverless environments such as Vercel, AWS Lambda, and Cloudflare Workers. Serverless SSR auto-scales on traffic spikes and provides SSR benefits without always-on servers. Next.js integrates with Vercel serverless by default.

Related Sources

이 페이지를 참조하는 항목

관련 항목

📙How-to
Indexing Coverage Diagnosis
Indexing coverage diagnosis uses the GSC indexing report to check overall site indexing status, identify causes of unindexed pages, and fix them — a core SEO task.
📘ConceptPillar
GEO Master Guide: 5-Area Checklist
An execution guide for Generative AI Optimization covering GEO's five areas: content, structure, technical, off-site, and measurement.
📘ConceptPillar
What Is AEO?
AEO is the practice of optimizing content so AI answer engines cite it.
📘Concept
Pagination
Pagination is a technique for splitting long content or product listings across multiple pages. Since rel=prev/next was deprecated in 2019, it is now managed through canonical tags, infinite scroll, and load more approaches.
📘ConceptPillar
Crawlability
Crawlability is the ability of search engine and AI bots to access website pages and read content. It is the most basic condition for SEO and AEO, a required step that precedes indexing and ranking.
📘Concept
Crawling vs Indexing
Crawling is the process where search engine bots follow links across the web and collect pages. Indexing is the process of analyzing collected pages and storing them in a search database. These are the first two stages of SEO’s three stages: crawling → indexing → ranking.
📘ConceptPillar
JavaScript SEO
JavaScript SEO is the technical SEO area of optimizing JavaScript-rendered web pages so search engines and AI bots recognize them correctly. The choice between SSR/SSG and CSR determines indexing feasibility.
📙How-to
How to Allow AI Bots in robots.txt
Allowing AI bots means explicitly permitting major AI crawlers such as GPTBot, ClaudeBot, and PerplexityBot to access your site in robots.txt, exposing your content for citation in generative AI answers.
📘ConceptPillar
Site Architecture
Site architecture is the overall design of page hierarchy, URL structure, and internal linking on a website. It simultaneously determines crawl efficiency, indexing quality, and user navigation experience — a foundational SEO element.
📘ConceptPillar
Subdomain vs Subdirectory
Subdomain (subdomain.example.com) and subdirectory (example.com/path/) are two URL structure choices for content. Subdirectories share domain authority and are advantageous in most SEO cases.
📘Concept
TTFB (Time to First Byte)
TTFB (Time to First Byte) is the time from a user’s URL request until the first byte is received from the server. It measures server response speed, is a core component of LCP, and is the starting point of all page performance.

이런 항목도 있어요

📘ConceptPillar
JavaScript SEO
JavaScript SEO is the technical SEO area of optimizing JavaScript-rendered web pages so search engines and AI bots recognize them correctly. The choice between SSR/SSG and CSR determines indexing feasibility.
📘ConceptPillar
Crawlability
Crawlability is the ability of search engine and AI bots to access website pages and read content. It is the most basic condition for SEO and AEO, a required step that precedes indexing and ranking.
📘Concept
Crawling vs Indexing
Crawling is the process where search engine bots follow links across the web and collect pages. Indexing is the process of analyzing collected pages and storing them in a search database. These are the first two stages of SEO’s three stages: crawling → indexing → ranking.
📘ConceptPillar
Site Architecture
Site architecture is the overall design of page hierarchy, URL structure, and internal linking on a website. It simultaneously determines crawl efficiency, indexing quality, and user navigation experience — a foundational SEO element.
이 페이지가 도움이 됐나요?