JavaScript 검색엔진 최적화

TL;DR — JavaScript SEO가 묻는 질문은 하나입니다. 검색엔진이 콘텐츠를 볼 수 있는가? 현대 사이트는 페이지의 많은 부분을 브라우저에서 JavaScript로 만듭니다. 중요한 텍스트와 링크가 스크립트 실행 후에만 나타난다면 Google이 여전히 접근할 수 있는지 확인해야 합니다. 대체로 가능하지만 세부 구현에서 문제가 생깁니다.

JavaScript SEO란

많은 사이트가 페이지의 일부 또는 전부를 브라우저에서 JavaScript로 만듭니다. 서버가 HTML 일부를 보내면 스크립트가 실행되어 콘텐츠를 채우고 항목을 더 불러오거나, 페이지 전체를 새로 고치지 않고 화면을 바꿉니다. JavaScript SEO는 검색엔진이 이런 콘텐츠를 계속 크롤링하고 렌더링하고 색인할 수 있도록 만드는 작업입니다.

Google에서는 다음 순서로 처리됩니다.

1. 크롤링 — Google이 URL의 원시 HTML을 다운로드합니다.
2. 렌더링 — Google이 브라우저에서 페이지의 JavaScript를 실행해 완성된 페이지를 만듭니다. 이것이 렌더링 단계입니다.
3. 색인 — Google이 완성된 페이지를 읽고 색인에 저장합니다.

Google은 JavaScript 웹 앱 처리 과정을 이 세 가지 주요 단계로 설명합니다.

콘텐츠가 JavaScript 실행 후에만 나타난다면 Google은 그 콘텐츠를 보기 전에 페이지를 성공적으로 렌더링해야 합니다. 대부분은 잘 처리하지만, 실패하면 콘텐츠가 검색결과에서 조용히 사라질 수 있습니다.

먼저 좋은 소식

JavaScript 자체는 SEO에 나쁘지 않습니다. Google은 최신 버전의 Chrome을 실행하며 방문자가 실행하는 것과 같은 JavaScript를 실행할 수 있습니다. “Google은 JavaScript를 읽지 못한다”는 오래된 걱정은 이제 사실이 아닙니다.

문제가 될 수 있는 지점은 더 구체적입니다.

• 콘텐츠를 불러오려면 클릭하거나 스크롤해야 하는데 Google은 클릭하거나 스크롤하지 않습니다. 이 주장에 대한 근거 Google Search does not interact with a page, so lazy-loaded content should load when it becomes visible in the viewport rather than requiring user interaction. 범위: Google Search's documented rendering behavior for lazy-loaded content; other crawlers can behave differently. 신뢰도: 높음 · 검증일: 2026-07-14 Google Search Central: Fix lazy-loaded content
• 링크가 실제 링크가 아니라 버튼이나 클릭 핸들러라서 Google이 따라갈 수 없습니다. 이 주장에 대한 근거 Google can reliably discover links only when they are HTML anchor elements with an href attribute. 범위: Link discovery by Google Search; this does not claim that every discovered URL will be crawled or indexed. 신뢰도: 높음 · 검증일: 2026-07-14 Google Search Central: Make your links crawlable
• robots.txt에서 JavaScript 또는 CSS 파일을 실수로 차단해 Google이 페이지를 제대로 렌더링하지 못합니다.
• 브라우저에서는 페이지가 정상으로 보이지만 Google의 렌더링된 화면에는 콘텐츠가 나타나지 않습니다.

          
            
            
          
          1
          <nav aria-label="Product categories">
        
          
            −
            삭제된 줄입니다. 
          
          2
          <button onclick="goTo('/shoes')">Shoes</button>
        
          
            −
            삭제된 줄입니다. 
          
          3
          <button onclick="goTo('/boots')">Boots</button>
        
          
            
            
          
          4
          </nav>
        

          
            
            
          
          1
          <nav aria-label="Product categories">
        
          
            +
            추가된 줄입니다. 
          
          2
          <a href="/shoes/">Shoes</a>
        
          
            +
            추가된 줄입니다. 
          
          3
          <a href="/boots/">Boots</a>
        
          
            
            
          
          4
          </nav>
        

간단한 체크리스트

• 원시 HTML(마우스 오른쪽 버튼 → 페이지 소스 보기)과 렌더링된 HTML(Google Search Console의 URL Inspection 도구)을 비교합니다. 렌더링된 화면에 중요한 콘텐츠가 없다면 바로 그 지점이 문제입니다.
• 링크가 <div>의 클릭 핸들러가 아니라 실제 <a href> 링크인지 확인합니다.
• robots.txt에서 JavaScript나 CSS 파일을 차단하지 않습니다.
• 콘텐츠를 불러오는 데 클릭이나 스크롤이 필요한 기능이라면 다른 경로로도 그 콘텐츠에 접근할 수 있게 합니다.
• 반드시 검색 순위에 노출되어야 할 콘텐츠에는 콘텐츠가 원시 HTML에 이미 들어 있는 서버 측 렌더링 또는 정적/사전 렌더링 빌드를 우선합니다. 이 주장에 대한 근거 Google describes server-side rendering or pre-rendering as a good idea because it makes a website faster for users and crawlers. 범위: Google Search guidance for JavaScript sites; the source does not prescribe one framework or guarantee indexing. 신뢰도: 높음 · 검증일: 2026-07-14 Google Search Central: Understand the JavaScript SEO basics

실제 실패 유형, 두 페이지가 하나로 색인되는 무한 스크롤 함정, 렌더링된 HTML 테스트 방법을 더 깊이 알고 싶다면 Advanced 탭으로 이동하세요. Google 렌더러의 작동 방식과 렌더링 구성을 고르는 법은 렌더링 페이지를 참고하세요.

TL;DR — Google은 JavaScript를 실행할 수 있으므로 “Google이 JS를 읽을 수 있는가?”는 잘못된 질문입니다. 실제 실패 유형은 동등성(원시 DOM과 렌더링된 DOM), 상호작용(Google은 스크롤하거나 클릭하지 않음), 상태(렌더러는 상태를 유지하지 않음), 타이밍입니다. 링크는 실제 <a href> 앵커로 만들고 JS/CSS를 차단하지 마세요. 상호작용이 아니라 viewport 진입 시 지연 로드하고, 클라이언트 측 404에는 실제 상태를 반환해야 합니다. 원시 HTML의 noindex 때문에 JavaScript가 이를 제거하기 전에 렌더링이 생략될 수도 있습니다. 실제로 처리된 지시문만 함께 판단하고 원시 또는 렌더링 버전이 항상 우선한다고 가정하지 마세요. 특히 무한 스크롤에서는 긴 렌더 viewport가 로더를 작동시켜 두 URL을 하나의 색인 페이지로 합칠 수 있습니다. 렌더러 내부 구조와 렌더링 모드 선택은 렌더링을 참고하세요.

Google이 JavaScript를 읽을 수 있는가? 그렇지만 핵심 질문은 아닙니다

Google은 JavaScript 앱을 세 단계로 처리합니다. “Google processes JavaScript web apps in three main phases: 1. Crawling 2. Rendering 3. Indexing.” (번역) 「Google은 JavaScript 웹 앱을 세 가지 주요 단계, 즉 1. 크롤링 2. 렌더링 3. 색인으로 처리합니다.」 가운데 단계에서는 최신 헤드리스 Chrome에서 JS를 실행해 색인할 DOM을 만듭니다. “Rendering is important because websites often rely on JavaScript to bring content to the page, and without rendering Google might not see that content.” (번역) 「웹사이트는 페이지에 콘텐츠를 표시하기 위해 JavaScript에 의존하는 경우가 많고, 렌더링하지 않으면 Google이 그 콘텐츠를 보지 못할 수 있으므로 렌더링이 중요합니다.」

따라서 Google은 JavaScript를 실행할 수 있습니다. 실용적인 질문은 더 구체적입니다.

• 동등성 — 렌더링된 DOM에 예상한 내용이 실제로 들어 있는가?
• 상호작용 — Google이 하지 않을 스크롤이나 클릭이 필요한 요소가 있는가?
• 상태 — 상태 없는 렌더러가 지우는 쿠키나 localStorage에 의존하는가?
• 타이밍 — 중요한 콘텐츠가 느리거나 늦게 실행되는 JavaScript 뒤로 밀려 있는가?

타이밍 측면에서 Google은 200을 반환한 크롤링 페이지를 렌더링 대기열에 넣으며, “the page may stay on this queue for a few seconds, but it can take longer than that.” (번역) 「페이지가 이 대기열에 몇 초 동안 머물 수 있지만 그보다 더 오래 걸릴 수도 있습니다.」 공개된 고정 지연 시간이나 제한 시간은 없습니다. 200이 아닌 상태를 반환하거나 처음부터 noindex 지시문이 있는 페이지는 JavaScript가 이를 바꾸기를 기다리지 않고 렌더링 대기열을 건너뛸 수 있습니다.

Web Rendering Service, 무상태성, 캐싱, ‘두 번의 색인 단계’ 오해 등 Google의 렌더링 메커니즘은 렌더링 페이지에서 다룹니다. 여기서는 실무 문제와 해결책에 집중합니다.

링크는 실제 <a href> 앵커여야 합니다

가장 흔한 JS SEO 오류입니다. “Google can only discover your links if they are <a> HTML elements with an href attribute.” (번역) 「Google은 링크가 href 속성이 있는 <a> HTML 요소일 때만 그 링크를 발견할 수 있습니다.」 onclick 핸들러가 달린 클릭 가능한 <div>는 Google에게 링크로 보이지 않습니다. 따라서 Google이 따라가지 않으며, 그 링크에 발견을 의존하는 페이지는 크롤링되지 않을 수 있습니다. JavaScript로 링크를 삽입하는 것은 괜찮지만 렌더링된 DOM에서 실제 <a href> 앵커가 되어야 합니다. 다만 렌더링된 앵커는 JavaScript 실행 후 파싱됩니다. DOM에 나타나면 발견 가능하다는 뜻일 뿐, URL의 크롤링·색인이나 원시 HTML 링크와 동일한 취급을 보장하지는 않습니다.

지연 로드 및 상호작용이 필요한 콘텐츠

렌더러는 호기심 많은 사용자처럼 행동하지 않습니다. “Google Search does not interact with your page.” (번역) 「Google 검색은 페이지와 상호작용하지 않습니다.」 스크롤, 클릭, hover를 하지 않으므로 이런 이벤트 뒤에서만 불러오는 콘텐츠는 보이지 않습니다.

Google은 사용자 행동이 아니라 콘텐츠가 viewport에 들어올 때 불러오라고 안내합니다. “make sure that your lazy-loading implementation loads all relevant content whenever it is visible in the viewport,” (번역) 「지연 로딩 구현이 관련 콘텐츠가 viewport에 보일 때마다 모두 불러오도록 하세요.」 또한 “don’t add lazy-loading to content that is likely to be immediately visible when a user opens a page.” (번역) 「사용자가 페이지를 열자마자 보일 가능성이 높은 콘텐츠에는 지연 로딩을 추가하지 마세요.」 IntersectionObserver 또는 이미지의 네이티브 loading="lazy"를 사용하고, 스크롤이나 클릭 핸들러는 사용하지 않아야 정상적인 렌더링 과정에서 콘텐츠가 로드됩니다.

무한 스크롤: 두 페이지가 하나로 색인될 때

거의 아무도 설명하지 않지만 이 문제만으로도 한 절을 할애할 가치가 있습니다.

Googlebot은 일반적인 브라우저 창보다 훨씬 긴 viewport에서 렌더링할 수 있습니다. Google은 정확한 렌더 viewport 크기를 공개하지 않고 그 크기도 바뀔 수 있으므로 특정 수치를 전제로 설계하지 말고 자체 구현을 테스트해야 합니다. 핵심은 작동 방식입니다. 무한 스크롤 로더가 스크롤 위치나 viewport 높이를 기준으로 실행된다면 예상보다 긴 렌더 viewport가 렌더링 도중 로더를 작동시킬 수 있습니다. 그러면 다음 글이나 제품 페이지의 콘텐츠가 같은 DOM에 추가됩니다. 서로 다른 두 URL의 콘텐츠가 함께 렌더링되고 Google이 이를 한 페이지로 색인할 수 있습니다. 내 경험상 “occasionally, two pages get indexed as one” (번역) 「때때로 두 페이지가 하나로 색인됩니다.」 ‘색인되지 않음’으로 보고된 페이지가 실제로는 다른 페이지, 대개 피드의 이전 글 일부로 색인된 사례가 있었습니다. 이유는 “when Google resized the viewport to be longer … it triggered the infinite scroll and loaded another article in when it was rendering.” (번역) 「Google이 viewport를 더 길게 조정했을 때 … 무한 스크롤이 작동해 렌더링 도중 다른 글을 불러왔기 때문입니다.」 특정 크기를 가정하거나 안전하다고 단정하지 말고, URL Inspection의 렌더링된 HTML에서 예상 지점에서 끝나야 하는 페이지가 실제로 그렇게 끝나는지 확인하세요.

이를 제대로 처리하려면 두 단계가 필요합니다.

먼저 무한 스크롤을 검색 친화적으로 만드세요. 무한 스크롤 아래에 페이지네이션 방식의 로딩을 지원합니다. 각 묶음에는 “its own persistent, unique URL,” (번역) 「지속적으로 유지되는 고유 URL」이 있어야 하고, URL을 불러올 때마다 콘텐츠가 같아야 하며, ?date=yesterday 같은 상대 매개변수는 피해야 합니다. 또한 “link sequentially to the individual URLs so that search engines can discover the URLs in a paginated set,” (번역) 「검색엔진이 페이지로 나뉜 집합의 URL을 발견할 수 있도록 각 URL을 순서대로 링크」하고, 스크롤로 새 묶음을 불러올 때는 “update the displayed URL using the History API.” (번역) 「History API를 사용해 표시된 URL을 업데이트」해야 합니다. 실제 <a href> 페이지네이션 링크와 고유 URL을 사용하세요. Google은 fragment 식별자를 무시하므로 페이지 번호에 “don’t use URL fragment identifiers” (번역) 「URL fragment 식별자(# 뒤 부분)를 사용하지 마세요.」 내 JavaScript SEO 가이드에서 말했듯, “if you have an infinite scroll setup, I still recommend a paginated page version so that Google can still crawl properly.” (번역) 「무한 스크롤을 사용하더라도 Google이 계속 제대로 크롤링할 수 있게 페이지네이션 버전을 권장합니다.」

오류가 있는 로더가 실제로 페이지를 합치고 있다면 가장 빠른 해결책은 단순합니다. “block the JavaScript file that handles the infinite scrolling so the functionality can’t trigger.” (번역) 「기능이 작동하지 않도록 무한 스크롤을 처리하는 JavaScript 파일을 차단하세요.」 렌더링 중 로더가 실행되지 않으면 다음 페이지 콘텐츠를 추가할 수 없고 각 URL은 다시 자기 콘텐츠만 렌더링합니다.

클라이언트 측 라우팅 이후의 소프트 404

SPA는 HTTP 상태 코드를 바꾸지 않고 콘텐츠를 교체할 수 있으므로 ‘찾을 수 없음’ 화면도 200을 반환할 수 있습니다. Google은 반환된 콘텐츠를 평가한 뒤 이 응답을 소프트 404로 분류할 수 있지만 정적 fetch만으로는 Google이 실제로 그렇게 분류했음을 증명할 수 없습니다. 해결책은 두 가지입니다. History API로 이동하고, 실제로 찾을 수 없는 상태라면 진짜 404를 반환하는 URL로 보내거나 noindex 태그를 추가합니다. 라우팅을 URL fragment에 의존하지 마세요. “the AJAX-crawling scheme has been deprecated since 2015, so you can’t rely on URL fragments to work with Googlebot.” (번역) 「AJAX 크롤링 방식은 2015년에 폐기되었으므로 URL fragment가 Googlebot에서 작동할 것이라고 기대할 수 없습니다.」

클라이언트 측 redirect에도 같은 증거 문제가 있습니다. JavaScript가 실행되기 전 초기 응답은 200으로 남을 수 있습니다. Google은 서버 측 또는 meta refresh redirect가 불가능할 때만 JavaScript redirect를 대안으로 지원합니다. 감사에서는 정적 상태와 관찰한 렌더링 후 이동을 별도로 보고하세요. HTTP 상태를 다시 쓰거나 렌더링 중 URL 변화 모두를 redirect라고 부르면 안 됩니다.

robots.txt에서 JavaScript 또는 CSS를 차단하지 마세요

Google은 차단된 파일이나 차단된 페이지의 JavaScript를 렌더링하지 않습니다. bundle이나 그 파일이 있는 /_next/, /static/, /assets/ 디렉터리를 robots.txt에서 차단하면 렌더링 전체가 깨질 수 있습니다. Google은 shell만 가져오고 스크립트를 실행하지 못해 빈 페이지를 색인하게 됩니다. URL Inspection의 페이지 리소스에서 차단된 항목을 확인하세요.

DOM 동등성과 처리 단계별 robots 지시문

원시 HTML(페이지 소스 보기)과 렌더링된 HTML(URL Inspection)을 비교합니다. 렌더링된 HTML에만 있는 콘텐츠도 렌더링에 성공하면 색인될 수 있습니다. 둘 다에 없으면 Google에도 존재하지 않습니다.

Google이 직접 문서화한 처리 순서 위험이 하나 있습니다. “When Google encounters the noindex tag, it may skip rendering and JavaScript execution, which means using JavaScript to change or remove the robots meta tag from noindex may not work as expected.” (번역) 「Google이 noindex 태그를 발견하면 렌더링과 JavaScript 실행을 건너뛸 수 있습니다. 따라서 JavaScript로 robots meta 태그의 noindex를 변경하거나 제거하는 방식은 예상대로 작동하지 않을 수 있습니다.」 원시 HTML이 처음부터 noindex를 내보내면 Google은 그 지시문에 따라 처리하고 이를 제거할 스크립트를 아예 실행하지 않을 수 있습니다.

이를 ‘항상 렌더링 버전이 우선한다’는 규칙으로 일반화하면 안 됩니다. 조정 방식은 필드마다 다릅니다.

따라서 감사자는 source, rendered, response header, 관찰된 검색 상태를 하나의 ‘유효 값’으로 합치지 말고 서로 구분해야 합니다.

콘텐츠를 DOM에 넣는 렌더링 모드를 선택하세요

JS SEO 위험의 대부분은 HTML을 어떻게 만드는지에서 생깁니다. SSR, 정적/사전 렌더링, hydration은 콘텐츠를 DOM에 넣거나 빠르게 추가하므로 검색 노출이 렌더러 성공에 의존하는 정도를 줄입니다. 완전한 클라이언트 측 렌더링은 매번 제시간에 올바르게 렌더링되는지에 더 크게 의존합니다. Dynamic rendering은 동급 선택지가 아니라 우회책입니다. 2025년 12월에 마지막으로 업데이트된 Google 안내에서도 장기 해법이 아닌 우회책으로 설명하며, 대신 서버 측 렌더링, 정적 렌더링 또는 hydration을 권장합니다. 내 JavaScript SEO 가이드 표현으로는 “any kind of SSR, static rendering, and prerendering setup is going to be fine for search engines.” (번역) 「어떤 형태든 SSR, 정적 렌더링, 사전 렌더링 구성은 검색엔진에 적합합니다.」 CSR, SSR, SSG, hydration, ISR, edge, streaming, dynamic rendering의 전체 비교표는 렌더링 페이지에 있습니다. Google은 별도로 서버 측 렌더링이나 사전 렌더링이 사용자와 크롤러에게 좋은 방법이라고 설명합니다. 이 주장에 대한 근거 Google describes server-side rendering or pre-rendering as a good idea because it makes a website faster for users and crawlers. 범위: Google Search guidance for JavaScript sites; the source does not prescribe one framework or guarantee indexing. 신뢰도: 높음 · 검증일: 2026-07-14 Google Search Central: Understand the JavaScript SEO basics

테스트 방법

Search Console의 URL Inspection이 기준입니다. 실시간 테스트를 실행한 뒤 렌더링된 HTML, 스크린샷, 페이지 리소스/콘솔 메시지를 확인해 무엇을 불러왔고 무엇이 실패했는지 살펴보세요. Rich Results Test로 렌더링된 HTML을 빠르게 확인할 수도 있습니다. 대규모 사이트에서는 JavaScript를 실행하는 크롤러(Ahrefs Site Audit, JavaScript 렌더링 모드의 Screaming Frog)를 사용해 사이트 전체의 원시 HTML과 렌더링 결과를 비교합니다.

JavaScript는 SEO에 나쁘거나 악한 것이 아닙니다. 많은 SEO 실무자에게 익숙한 방식과 다를 뿐입니다. 개발자와 협업하고 중요한 콘텐츠를 DOM에 넣은 다음, 추측이 아니라 Google 도구로 실제 렌더링 결과를 판단하세요.

다음 단계: JavaScript SEO 클러스터

이 허브는 전체 지도입니다. 아래 각 주제에는 별도의 심층 가이드가 있습니다.

렌더링과 아키텍처

• 헤드리스 CMS SEO — 분리된 frontend가 크롤링, 렌더링, metadata, sitemap, canonical 태그에 미치는 영향, 렌더링 모드 선택, 헤드리스 환경의 고유 실패 유형을 설명합니다.

프레임워크별 가이드

• React SEO — CSR 우선 React의 색인 위험, Google의 React 앱 렌더링, React Router와 History API, meta 태그용 react-helmet-async, Next.js를 선택할 시점.
• Angular SEO — Angular의 SPA 기본값, @angular/ssr(Angular Universal 후속), 내장 Title 및 Meta 서비스, 사전 렌더링, 최신 Angular의 incremental hydration.
• Next.js SEO — Pages Router와 App Router, Metadata API, next/image와 CWV, ISR 타이밍과 Googlebot, sitemap, 흔한 Next.js SEO 실수.
• Nuxt SEO — 기본 SSR, useSeoMeta(), Nuxt 렌더링 모드, @nuxtjs/seo 모듈 생태계, 색인 가능성 측면에서 일반 Vue와의 비교.
• Vue SEO — Vue 3의 CSR 기본값과 크롤러에 미치는 영향, createWebHistory(), @unhead/vue, meta-framework 없이 쓸 수 있는 사전 렌더링, Nuxt가 적합한 시점.
• Svelte SEO — Svelte와 SvelteKit, SvelteKit의 기본 SSR, <svelte:head>, adapter-static + ssr: false 함정, adapter 선택, AI 크롤러에 미치는 영향.
• Astro SEO — 기본 zero-JS, islands architecture, @astrojs/sitemap, astro:assets, View Transitions와 History API, Server Islands fallback 동작, Astro의 Core Web Vitals 장점.

AI 요약

Advanced 버전의 핵심을 압축하면 다음과 같습니다.

• “Google이 JS를 읽을 수 있는가?”는 잘못된 질문입니다. Google은 읽을 수 있습니다. 실제 실패 유형은 동등성, 상호작용, 상태, 타이밍입니다.
• 타이밍에 고정 지연 시간은 없습니다. Google은 200 페이지를 렌더링 대기열에 넣고 몇 초 또는 그 이상 기다릴 수 있습니다. 공개된 제한 시간은 없고, 200이 아닌 상태나 초기 noindex는 렌더링 대기열을 완전히 건너뛸 수 있습니다.
• 링크는 실제 <a href> 앵커여야 합니다. <div>의 onclick은 링크로 발견되지 않습니다. JS로 링크를 추가해도 렌더링된 앵커가 되면 발견할 수 있지만 크롤링이나 색인을 보장하지는 않습니다.
• 상호작용이 아니라 viewport를 기준으로 지연 로드하세요. Google은 페이지와 상호작용하지 않습니다. IntersectionObserver 또는 네이티브 지연 로딩을 쓰고 스크롤이나 클릭 뒤에 콘텐츠를 숨기지 마세요.
• 무한 스크롤은 두 페이지를 하나로 합칠 수 있습니다. 일반 브라우저보다 긴 Googlebot의 렌더 viewport가 로더를 작동시켜 다음 페이지 콘텐츠를 붙일 수 있습니다. 고유한 페이지네이션 URL, 실제 <a href> 링크, History API를 사용하고 페이지를 합치는 로더라면 JS 파일을 차단하세요.
• 클라이언트 측 라우팅 이후 소프트 404에는 실제 404 또는 noindex를 반환하고, 2015년에 폐기된 AJAX 크롤링 방식의 URL fragment에 의존하지 마세요.
• robots.txt에서 JS/CSS를 차단하지 마세요. 차단된 파일은 Google이 렌더링하지 않습니다.
• noindex는 자기 자신의 제거를 막을 수 있습니다. 초기 noindex를 본 Google이 렌더링을 건너뛰면 제거용 JS가 실행되지 않습니다.
• DOM 동등성과 처리 단계를 함께 보되 robots meta 태그에 실제로 처리된 지시문만 결합 규칙을 적용하고 canonical은 별도 규칙으로 확인합니다.
• 렌더링 모드는 의존도를 바꿀 뿐 결과를 보장하지 않습니다. SSR, 정적/사전 렌더링, hydration은 DOM에 콘텐츠를 더 일찍 넣고, 완전한 CSR의 렌더링 의존도가 가장 높습니다. Dynamic rendering은 우회책입니다.
• URL Inspection, Rich Results Test, JavaScript 렌더링 크롤러로 테스트하세요.

공식 문서

검색엔진의 1차 출처 문서입니다.

Google

• JavaScript SEO 기본사항 이해 — 세 단계, 크롤링 가능한 링크, 렌더링된 HTML 테스트.
• 검색 관련 JavaScript 문제 해결 — 소프트 404 처리, History API, 렌더러 제약.
• 지연 로드 콘텐츠 수정 — 상호작용이 아닌 viewport에서 로드하는 법과 검색 친화적 무한 스크롤.
• 전자상거래 페이지네이션 및 점진적 페이지 로딩 — 고유 URL, <a href> 링크, Google이 fragment 식별자를 무시하는 이유.
• Google 검색 작동 방식 심층 가이드 — 크롤링 → 색인 → 게재 과정에서 렌더링의 위치.

Bing / Microsoft

• bingbot 시리즈: JavaScript, Dynamic Rendering, Cloaking — JavaScript 렌더링과 dynamic rendering에 대한 Bing의 설명.

출처의 인용문

Google의 공식 발언과 필자의 글에서 가져온 일부 인용문입니다. 각 검색엔진 링크는 출처 페이지의 인용 구절로 바로 이동합니다.

Google — 렌더링과 링크

• “Google processes JavaScript web apps in three main phases: 1. Crawling 2. Rendering 3. Indexing.” (번역) 「Google은 JavaScript 웹 앱을 세 가지 주요 단계, 즉 1. 크롤링 2. 렌더링 3. 색인으로 처리합니다.」 인용문으로 이동
• “Google can only discover your links if they are <a> HTML elements with an href attribute.” (번역) 「Google은 링크가 href 속성이 있는 <a> HTML 요소일 때만 그 링크를 발견할 수 있습니다.」 인용문으로 이동
• “Rendering is important because websites often rely on JavaScript to bring content to the page, and without rendering Google might not see that content.” (번역) 「웹사이트는 페이지에 콘텐츠를 표시하기 위해 JavaScript에 의존하는 경우가 많고, 렌더링하지 않으면 Google이 그 콘텐츠를 보지 못할 수 있으므로 렌더링이 중요합니다.」 인용문으로 이동
• “The page may stay on this queue for a few seconds, but it can take longer than that.” (번역) 「페이지가 이 대기열에 몇 초 동안 머물 수 있지만 그보다 더 오래 걸릴 수도 있습니다.」 렌더링 대기열의 고정 지연 시간은 공개되지 않았습니다. 인용문으로 이동
• “When Google encounters the noindex tag, it may skip rendering and JavaScript execution, which means using JavaScript to change or remove the robots meta tag from noindex may not work as expected.” (번역) 「Google이 noindex 태그를 발견하면 렌더링과 JavaScript 실행을 건너뛸 수 있습니다. 따라서 JavaScript로 robots meta 태그의 noindex를 변경하거나 제거하는 방식은 예상대로 작동하지 않을 수 있습니다.」 인용문으로 이동

Google — 상호작용, 지연 로드, 무한 스크롤

• “Google Search does not interact with your page.” (번역) 「Google 검색은 페이지와 상호작용하지 않습니다.」 인용문으로 이동
• “…loads all relevant content whenever it is visible in the viewport.” (번역) 「관련 콘텐츠가 viewport에 보일 때마다 모두 불러옵니다.」 인용문으로 이동
• “Give each chunk its own persistent, unique URL.” (번역) 「각 묶음에 지속적으로 유지되는 고유 URL을 부여하세요.」 검색 친화적 무한 스크롤 지침입니다. 인용문으로 이동
• “Don’t use URL fragment identifiers (the text after a # in a URL) for page numbers in a collection. Google ignores fragment identifiers.” (번역) 「컬렉션의 페이지 번호에 URL fragment 식별자(URL의 # 뒤 텍스트)를 사용하지 마세요. Google은 fragment 식별자를 무시합니다.」 인용문으로 이동

Google — 소프트 404와 라우팅

• “We recommend using the History API to load different views.” (번역) 「서로 다른 화면을 불러올 때 History API를 사용하는 것이 좋습니다.」 인용문으로 이동

Patrick Stox (필자의 글 — JavaScript SEO: A Definitive Guide)

• robots meta 태그에 관해: “With meta robots tags, Google is always going to take the most restrictive option it sees — no matter the location… Google will choose the most restrictive statements between HTML and the rendered version of a page.” (번역) 「meta robots 태그에서는 위치와 관계없이 Google이 발견한 가장 제한적인 옵션을 선택합니다. … Google은 HTML과 렌더링된 페이지 버전 사이에서 가장 제한적인 지시문을 선택합니다.」
• “If you have an infinite scroll setup, I still recommend a paginated page version so that Google can still crawl properly.” (번역) 「무한 스크롤을 사용하더라도 Google이 계속 제대로 크롤링할 수 있게 페이지네이션 버전을 권장합니다.」
• 병합 문제에 관해: “occasionally, two pages get indexed as one” (번역) 「때때로 두 페이지가 하나로 색인됩니다.」 원인은 “Google resized the viewport to be longer … it triggered the infinite scroll and loaded another article in when it was rendering.” (번역) 「Google이 viewport를 더 길게 조정했을 때 … 무한 스크롤이 작동해 렌더링 도중 다른 글을 불러왔기 때문입니다.」 해결책은 “block the JavaScript file that handles the infinite scrolling so the functionality can’t trigger.” (번역) 「기능이 작동하지 않도록 무한 스크롤을 처리하는 JavaScript 파일을 차단하세요.」입니다.

JavaScript SEO 체크리스트

Google이 JavaScript 의존 콘텐츠를 렌더링하고 색인할 수 있는지 빠르게 확인하는 목록입니다.

• 중요한 콘텐츠가 렌더링된 HTML에 나타납니다. 페이지 소스만 보지 말고 URL Inspection으로 확인합니다.
• 링크는 <div>/<span>의 onclick이 아니라 실제 <a href> 앵커입니다.
• JavaScript와 CSS 파일이 robots.txt에서 차단되지 않았습니다.
• 콘텐츠가 클릭, 스크롤, hover 뒤에 숨겨져 있지 않습니다. IntersectionObserver 또는 loading="lazy"로 viewport 진입 시 지연 로드합니다.
• 첫 화면 콘텐츠를 지연 로드하지 않습니다.
• 원시 HTML과 렌더링된 HTML의 robots 지시문이 일치하며 JS가 noindex를 삽입하지 않습니다.
• 없는 리소스에 도달한 클라이언트 측 경로는 실제 404 또는 noindex를 반환합니다.
• 무한 스크롤에 고유 <a href> URL을 가진 페이지네이션 버전과 History API 업데이트가 있고, 긴 viewport에서 페이지를 합치지 않습니다.
• 검색 순위가 중요한 콘텐츠에는 완전한 CSR이 아니라 SSR/정적/사전 렌더링을 사용합니다.
• URL Inspection 실시간 테스트에서 렌더링된 스크린샷과 콘솔 오류를 표본 점검했습니다.

사고 모델

1. “Google이 내 JS를 실행할 수 있는가?”는 잘못된 질문입니다. 실행할 수 있습니다. 실제 질문은 동등성, 상호작용, 상태, 타이밍입니다.

• 동등성 — 렌더링된 DOM에 예상한 콘텐츠가 있는가?
• 상호작용 — Google이 하지 않을 스크롤이나 클릭이 필요한가?
• 상태 — 상태 없는 렌더러가 지우는 쿠키나 localStorage에 의존하는가?
• 타이밍 — 중요 콘텐츠가 느리거나 늦게 실행되는 JS 뒤로 밀려 있는가?

2. 렌더링된 DOM에 없으면 존재하지 않는 것과 같습니다. 페이지 소스는 원시 HTML을, URL Inspection은 렌더링된 DOM을 보여 줍니다. 색인 판단에는 렌더링된 DOM이 사용되므로 매번 이 결과물을 확인하세요.

3. 실제 링크가 아니면 링크가 아닙니다. 발견은 <a href> 앵커를 통해 이루어집니다. 앵커를 만들지 않는 클릭 핸들러, 버튼, JS 탐색은 크롤링의 막다른 길입니다.

4. 페이지를 전혀 만지지 않는 봇을 위해 설계하세요. 스크롤, 클릭, hover를 하지 않습니다. 동작해야 콘텐츠가 나타난다면 Google이 보지 못한다고 가정하고 viewport 진입 시 불러오세요.

5. 무한 스크롤의 긴 viewport 함정을 테스트하세요. Googlebot은 일반 브라우저보다 긴 viewport에서 렌더링할 수 있으며 정확한 고정 크기는 공개되지 않았습니다. 스크롤/높이 기반 로더가 렌더링 도중 실행되어 다음 페이지를 합칠 수 있습니다. 페이지네이션 URL, 실제 링크, History API를 사용하고 실제로 병합한다면 로더 JS를 차단하세요.

6. 도구가 판단하게 하세요. 브라우저는 Googlebot이 아닙니다. “내 컴퓨터에서는 잘 보인다”는 말보다 URL Inspection의 렌더링된 HTML, 스크린샷, 콘솔이 기준입니다.

JavaScript SEO 함정 요약표

렌더링 모드 선택(성공적인 렌더링에 대한 의존도)

이 표가 결과를 보장하지는 않습니다. SSR/SSG/hydration도 올바르게 렌더링되고 다른 모든 검사를 통과해야 합니다. ISR, edge, streaming, dynamic rendering과 trade-off는 렌더링 페이지를 참고하세요.

Googlebot이 보는 내용 확인하기

렌더링 오류는 서버가 보내는 원시 HTML과 JS 실행 후 존재하는 렌더링된 HTML의 차이에 숨어 있습니다. 전체 크롤러를 사용하기 전에 명령줄에서 빠르게 확인할 수 있습니다.

원시 HTML 가져오기(JS 실행 전 응답)

macOS / Linux:

# Raw HTML as the server sends it — this is the "first fetch"
curl -sL -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" \
  https://example.com/page/ -o raw.html

# Is your important text actually in the raw HTML? (empty result = JS-dependent)
grep -o "Your headline text" raw.html

Windows (PowerShell):

$ua = "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
Invoke-WebRequest -Uri "https://example.com/page/" -UserAgent $ua -OutFile raw.html
Select-String -Path raw.html -Pattern "Your headline text"

텍스트가 raw.html에는 없지만 브라우저에는 보인다면 JavaScript가 추가한 것이므로 렌더링에 의존합니다. 렌더링된 HTML은 URL Inspection의 ‘크롤링된 페이지 보기 → 렌더링된 HTML’ 또는 헤드리스 Chrome 크롤러로 확인하세요. 일반 curl은 JS를 실행하지 못합니다.

robots.txt에서 JS/CSS를 차단하지 않았는지 확인하기

macOS / Linux:

curl -sL https://example.com/robots.txt | grep -iE "disallow.*\.(js|css)|Disallow:\s*/(_next|static|assets|dist)"

Windows (PowerShell):

(Invoke-WebRequest "https://example.com/robots.txt").Content |
  Select-String -Pattern "Disallow.*\.(js|css)","Disallow:\s*/(_next|static|assets|dist)"

JavaScript나 CSS와 일치하는 Disallow가 있으면 Google이 페이지를 제대로 렌더링하지 못합니다. 거의 항상 실수입니다. URL Inspection의 차단된 페이지 리소스 목록도 함께 확인하세요.

JavaScript SEO 디버깅 도구

Render Gap으로 원시 HTML과 Google 렌더링 결과의 차이를 확인하세요.

1. 테스트할 페이지의 전체 URL을 붙여 넣습니다. JavaScript 의존도가 높은 template 페이지가 가장 적합합니다.
2. 악용 방지 검사를 통과하고 Test page를 누릅니다. 먼저 원시 HTML을 가져오고, 빈 shell처럼 보일 때만 헤드리스 Chrome으로 렌더링합니다.
3. 색상으로 구분된 판정을 읽은 뒤 Initial HTML vs Rendered DOM 표에서 changed로 표시된 행을 확인합니다.
4. Raw vs rendered diff 탭으로 전환해 JavaScript가 추가하거나 제거한 내용을 줄 단위로 봅니다.

• URL Inspection (Google Search Console) — 기준 도구입니다. 실시간 테스트를 실행하고 렌더링된 HTML, 스크린샷, 페이지 리소스, JavaScript 콘솔 메시지를 봅니다.
• Rich Results Test — 사이트 소유권 확인 없이 URL의 렌더링된 HTML과 구조화 데이터를 빠르게 검사합니다.
• Chrome DevTools — 페이지 소스 보기(원시 HTML)와 Elements 패널(렌더링된 DOM)을 비교하고 Console에서 페이지를 비울 수 있는 JS 오류를 찾습니다.
• JavaScript 렌더링 크롤러 — Ahrefs Site Audit과 Screaming Frog SEO Spider의 JS 렌더링 모드로 대규모 비교를 수행합니다.
• 렌더링 소스 보기 도구 — 렌더링된 DOM과 원시 HTML을 나란히 보여 주는 브라우저 확장 프로그램입니다.
• 서버 로그 분석 — Googlebot이 실제로 JS/CSS 리소스를 가져오는지 확인합니다. 로그 파일 분석도 참고하세요.

JavaScript SEO 진단용 프롬프트

원시 HTML과 렌더링된 HTML 비교

같은 URL의 원시 응답과 렌더링된 DOM을 붙여 넣으세요. 먼저 고객 데이터와 token을 제거합니다.

Act as a technical SEO reviewer. Compare RAW_HTML and RENDERED_HTML below. Report only
meaningful differences in title, meta robots, canonical, headings, body copy,
structured data, and crawlable <a href> links. For each difference, label its likely
indexing impact, show the exact conflicting snippets, and give a verification step.
Do not infer content that is not present.

RAW_HTML:
[paste]

RENDERED_HTML:
[paste]

경로 표본 분류

Review this CSV of JavaScript routes with columns URL, HTTP_STATUS, RAW_TITLE,
RENDERED_TITLE, RAW_CANONICAL, RENDERED_CANONICAL, RAW_WORDS, RENDERED_WORDS. Group
failures into shared-shell duplicates, restrictive-directive conflicts, soft 404s,
and likely render timeouts. Rank groups by affected URL count. Return the exact rows
that support each conclusion and a test to confirm it; do not invent thresholds.

[paste CSV]

JavaScript SEO 변경 검증

JavaScript 실행 전에 경로 콘텐츠가 있는지 증명하기

실행할 테스트: 대표 경로를 curl로 가져와 response body를 검사합니다. 예상 결과: 각 응답에 고유 title, 주요 heading, copy, 크롤링 가능한 링크가 있습니다. 실패 해석: 배포가 여전히 공통 app shell을 제공합니다. 모니터링 시점: 즉시. 롤백 조건: 이전에는 서버에서 보이던 경로가 렌더링에 의존하게 됩니다.

처리 단계 사이의 지시문 일치 증명하기

실행할 테스트: 원시 HTML과 URL Inspection의 렌더링된 HTML에서 robots와 canonical 태그를 비교합니다. 예상 결과: 의도한 지시문 한 세트가 양쪽에 나타나고 원시 shell에 더 제한적인 값이 없습니다. 실패 해석: JavaScript가 색인 신호를 너무 늦게 덮어쓰려 합니다. 모니터링 시점: 로컬 렌더링에서는 즉시, Search Console에서는 재크롤링 이후. 롤백 조건: 어느 단계에서든 noindex 또는 잘못된 canonical이 나타납니다.

링크가 크롤링 가능한 상태인지 증명하기

실행할 테스트: JavaScript를 끄고 대표 경로로 이동하는 navigation을 검사합니다. 예상 결과: 목적지가 실제 anchor href 속성에 남아 있습니다. 실패 해석: 링크가 아니라 클라이언트 handler가 발견 경로를 담당합니다. 모니터링 시점: 즉시. 롤백 조건: 스크립트 실패 시 중요한 경로가 link graph에서 사라집니다.

참고할 만한 자료

내 관련 글

• JavaScript SEO: A Definitive Guide — 렌더링, DOM 동등성, 가장 제한적인 지시문 규칙, 무한 스크롤, 두 페이지가 하나가 되는 문제를 다루는 전체 가이드.
• The Beginner’s Guide to Technical SEO — 기술 SEO 전체에서 JavaScript SEO가 차지하는 위치.

내 발표

• How Search Works — 크롤링, 렌더링, 색인, 순위를 설명한 발표. “이는 시스템에 대한 나의 이해이며 100% 완전하거나 정확하지 않을 수 있다”는 기존 단서가 적용됩니다.

다른 출처

• r/TechSEO — 렌더링/색인 문제를 디버깅하는 커뮤니티.
• web.dev — Rendering on the Web — Chrome 팀의 렌더링 trade-off 설명.
• Google Search Central — JavaScript SEO — 세 단계, 크롤링 가능한 링크, 렌더링된 HTML 테스트에 관한 공식 1차 문서.
• Onely — JavaScript SEO 허브 — 렌더링, 두 단계 색인, JS SEO 감사에 관한 전문 기술 글.
• Martin Splitt의 JavaScript SEO 재생목록 — Google 웹 생태계 팀이 제작한 공식 동영상 시리즈.
• Search Engine Journal — JavaScript SEO — JS 렌더링 문제에 관한 업계 뉴스와 실무 가이드.

팟캐스트

• Search Off the Record(구글 검색 홍보팀) — Martin Splitt, John Mueller, Gary Illyes가 JavaScript SEO와 렌더링을 내부 관점에서 자주 다룹니다. 듣기

동영상

• Google Search Central(YouTube) — Martin Splitt의 JavaScript SEO 시리즈는 Google이 JS를 처리하는 방식을 설명하는 최고의 공식 동영상 가이드입니다. 채널

인용할 만한 통계와 현재 설명

• 현재 공식 설명: 고정 지연 시간 없음. 2026-03-04에 업데이트된 Google 문서에는 200으로 크롤링된 페이지가 “may stay on this queue for a few seconds, but it can take longer than that” (번역) 「이 대기열에 몇 초 동안 머물 수 있지만 그보다 더 오래 걸릴 수도 있다」고 나옵니다. 공개된 고정 지연이나 timeout은 없으며, 200이 아닌 상태 또는 초기 noindex가 있는 페이지는 렌더링을 완전히 건너뛸 수 있습니다. 인용문으로 이동
• 과거 자료 — 렌더링 지연 중앙값 약 5초. 과거 발표에서 Google 직원 Martin Splitt와 Tom Greenaway는 페이지가 렌더러에 도달하는 시간의 중앙값이 약 5초, 90번째 백분위수가 몇 분이라고 설명했습니다. 오래된 ‘몇 주’라는 우려와는 달랐습니다. 내 JavaScript SEO 가이드에서 이를 인용했습니다. Google이 현재 지표로 다시 발표하지 않았으므로 지금도 보편적으로 적용되는 수치가 아니라 당시 발표의 과거 자료로만 취급하세요.
• Martin Splitt의 2019년 발언에 따르면 ‘두 번의 색인 단계’의 영향은 줄고 있습니다. 2019년 8월 John Mueller와의 대화에서 Splitt는 렌더링 비용이 낮아지고 크롤링, 렌더링, 색인이 수렴하면서 두 단계 색인이 “play[s] less and less of a role” (번역) 「점점 더 작은 역할을 한다」고 말했습니다. 완전히 사라질 시점은 제시하지 않았습니다. 관련 보도 이는 Google의 최신 규격이 아니라 당시 Splitt의 설명이므로 현재 보장 사항이 아닌 방향성 맥락으로 사용하세요.

Google은 JavaScript 앱을 크롤링, 렌더링, 색인의 세 단계로 처리합니다. 이 주장에 대한 근거 Google processes JavaScript web apps in three main phases: crawling, rendering, and indexing; without rendering, Google might not see JavaScript-provided content. 범위: Google Search's processing of JavaScript pages; successful rendering does not guarantee indexing or ranking. 신뢰도: 높음 · 검증일: 2026-07-14 Google Search Central: Understand the JavaScript SEO basics 일반적으로 href 속성이 있는 앵커 링크를 크롤링합니다. 이 주장에 대한 근거 Google can reliably discover links only when they are HTML anchor elements with an href attribute. 범위: Link discovery by Google Search; this does not claim that every discovered URL will be crawled or indexed. 신뢰도: 높음 · 검증일: 2026-07-14 Google Search Central: Make your links crawlable Google은 서버 측 렌더링 또는 사전 렌더링이 사용자와 크롤러에게 좋은 방법이라고 설명합니다. 이 주장에 대한 근거 Google describes server-side rendering or pre-rendering as a good idea because it makes a website faster for users and crawlers. 범위: Google Search guidance for JavaScript sites; the source does not prescribe one framework or guarantee indexing. 신뢰도: 높음 · 검증일: 2026-07-14 Google Search Central: Understand the JavaScript SEO basics 또한 Google 검색은 콘텐츠를 작동시키기 위해 페이지와 상호작용하지 않습니다. 이 주장에 대한 근거 Google Search does not interact with a page, so lazy-loaded content should load when it becomes visible in the viewport rather than requiring user interaction. 범위: Google Search's documented rendering behavior for lazy-loaded content; other crawlers can behave differently. 신뢰도: 높음 · 검증일: 2026-07-14 Google Search Central: Fix lazy-loaded content

변경 내역