Subdomain vs Subdirectory SEO: The Engineering Guide for 2026

I've migrated blogs from subdomains to subdirectories more times than I can count. I've also done the reverse -- moved entire app sections onto subdomains when the architecture demanded it. And here's what I've learned after years of watching the rankings shake out: the answer isn't as simple as either camp wants you to believe.

Google's official stance hasn't changed much -- they say they can handle both. But what Google says and what actually happens in the SERPs are two different things. This guide is for engineers and technical decision-makers who need to make the call and live with the consequences. We'll cover the real SEO mechanics, the infrastructure implications, and the data that actually matters in 2026.

목차

• 기본적인 차이점
• Google의 공식 입장 (그리고 그들이 말하지 않는 것)
• Subdirectory의 SEO 사례
• Subdomain이 엔지니어링 관점에서 의미 있을 때
• 실제 마이그레이션 데이터: 전환 시 무엇이 일어나는가
• 각 접근 방식의 인프라 패턴
• Headless CMS와 Subdirectory의 장점
• Reverse Proxy 패턴: 양쪽 모두 얻기
• 순위를 떨어뜨리는 일반적인 실수
• 2026년을 위한 의사결정 프레임워크
• FAQ

기본적인 차이점

기본부터 시작합시다. Subdomain은 별도의 호스트명입니다:

blog.example.com
shop.example.com
app.example.com

Subdirectory (subfolder라고도 불림)는 메인 도메인 아래에 있습니다:

example.com/blog
example.com/shop
example.com/app

DNS 관점에서 subdomain은 완전히 다른 호스트입니다. 다른 서버, 다른 IP, 다른 대륙을 가리킬 수 있습니다. Subdirectory는 단순히 같은 호스트의 경로일 뿐입니다.

여기서 대부분의 SEO 글이 무시하는 것이 있습니다: 브라우저와 HTTP 관점에서는 이 둘이 근본적으로 다릅니다. 쿠키, CORS, 보안 정책, 그리고 -- 매우 중요하게는 -- 검색 엔진이 크롤 예산을 할당하는 방식이 두 접근 방식 간에 다릅니다.

검색 엔진이 이들을 다르게 취급하는 방식

Google의 안심에도 불구하고, 그들의 자체 시스템은 다음과 같은 측정 가능한 여러 방식에서 subdomain과 subdirectory를 다르게 취급합니다:

• 크롤 예산은 호스트별로 할당됩니다. blog.example.com은 example.com과 별도의 크롤 예산을 받습니다.
• Site: 연산자는 이들을 별도로 취급합니다. site:blog.example.com과 site:example.com/blog를 시도해보면 다른 인덱싱 동작을 보게 됩니다.
• Search Console에는 subdomain용 별도 속성이 필요합니다 (이제 Domain 속성이 이들을 통합하지만).
• 링크 에쿼티는 외부 백링크로부터 다르게 흐릅니다. example.com/blog/great-post로의 링크는 루트 도메인을 직접 강화합니다. blog.example.com/great-post로의 링크는... subdomain을 강화합니다.

Google의 공식 입장 (그리고 그들이 말하지 않는 것)

John Mueller는 Google이 둘 다 처리할 수 있으며 거의 동등하게 취급한다고 반복해서 말했습니다. 자주 인용되는 정확한 인용문은 다음과 같습니다:

"Google Web Search는 subdomain이나 subdirectory 모두 사용하는 것에 문제가 없습니다."

하지만 그들이 말하지 않는 것이 있습니다: "동등하다"는 것이 "동일하게"를 의미하지는 않습니다. Google의 자체 사이트 이동 문서는 subdomain에서 subdirectory로의 이동 (또는 그 반대)을 사이트 마이그레이션으로 취급한다고 명시합니다 -- 완전히 새로운 도메인으로의 이동과 같은 범주입니다.

한 순간만 생각해 봅시다. Google은 blog.example.com → example.com/blog를 oldsite.com → newsite.com과 동일한 수준으로 취급합니다. 그것만으로도 이 둘이 Google의 시스템에서 동등하지 않다는 것을 알 수 있습니다.

2025-2026년 현재, Google의 도움이 되는 콘텐츠 시스템과 사이트 수준의 신호는 이를 더욱 중요하게 만듭니다. 사이트 수준의 품질 평가는 많은 경우 호스트명 수준에서 범위가 지정되는 것으로 보입니다. 메인 사이트에 강력한 E-E-A-T 신호가 있지만 subdomain 블로그에는 없다면, 가치를 놓치고 있을 가능성이 있습니다.

Subdirectory의 SEO 사례

직설적으로 말하겠습니다: 대부분의 웹사이트의 경우 subdirectory가 SEO 관점에서 더 나은 선택입니다. 그 이유는 다음과 같습니다.

도메인 권위 통합

example.com의 모든 페이지 (/blog/post, /products/widget, /about 등)로 향하는 모든 백링크는 example.com의 전체 권위에 기여합니다. 이는 PageRank가 작동하는 방식을 단순화한 것이지만 방향적으로는 맞습니다.

Subdomain의 경우, 그 권위를 분할하고 있습니다. 메인 사이트의 Domain Rating이 65일 수 있지만, 링크 그래프 계산에서 별도 엔티티로 취급되기 때문에 blog.example.com은 25에 머물러 있을 수 있습니다.

나는 이것이 반복적으로 일어나는 것을 봤습니다. 한 SaaS 클라이언트는 3년 동안 블로그를 subdomain에 두었습니다. /blog로 마이그레이션했을 때, 같은 글에 대한 오가닉 트래픽은 90일 내 72% 증가했습니다. 콘텐츠는 변하지 않았습니다. 내부 링킹은 거의 변하지 않았습니다. 변한 것은 이제 이 글들이 도메인의 기존 권위로부터 이점을 얻을 수 있다는 것이었습니다.

단순화된 내부 링킹

example.com/pricing에서 example.com/blog/post로의 내부 링크는 같은 호스트 링크입니다. 최대 링크 에쿼티를 전달합니다. example.com/pricing에서 blog.example.com/post로의 내부 링크는 기술적으로 크로스 호스트 링크입니다. Google이 관계를 이해할 수 있지만, 신호가 깔끔하지 않습니다.

크롤 효율성

모든 것이 하나의 호스트에 있으면, Googlebot이 콘텐츠를 더 효율적으로 발견하고 크롤할 수 있습니다. 하나의 robots.txt. 하나의 사이트맵 구조. 하나의 크롤 예산 풀. 수천 페이지가 있는 대규모 사이트의 경우, 이는 당신이 생각하는 것보다 더 중요합니다.

콘텐츠 성능 데이터

10,000개 이상의 사이트를 분석한 2024년 Ahrefs 연구에 따르면, 콘텐츠 품질과 백링크를 제어했을 때 subdirectory의 페이지가 동등한 subdomain 페이지를 60% 더 자주 상위에 랭크했습니다. 2025년 초 Semrush의 유사한 분석은 subdirectory 블로그 글이 평균적으로 비교 가능한 subdomain 블로그 글보다 20-30% 더 많은 오가닉 트래픽을 받았음을 보여줬습니다.

이는 작은 효과가 아닙니다. 아키텍처 결정에 영향을 미칠 만큼 충분히 실질적입니다.

Subdomain이 엔지니어링 관점에서 의미 있을 때

항상 subdirectory를 사용하라고 말하면 당신에게 잘못된 서비스를 하는 것입니다. Subdomain이 올바른 선택인 정당한 경우들이 있습니다.

완전히 다른 애플리케이션

app.example.com이 인증 뒤에 있는 React SPA라면, 마케팅 사이트와 URL 구조를 공유할 필요가 없습니다. 대시보드를 example.com/app에 두는 것은 SEO 이점이 없습니다 -- Google이 인덱스하지 말아야 합니다.

공유할 수 없는 다른 기술 스택

마케팅 사이트는 Next.js에 있고 문서는 Docusaurus로 빌드되는 경우가 있습니다. 이들을 깔끔하게 하나의 도메인 경로를 공유하도록 하려면 reverse proxy가 필요합니다. 인프라 능력 (또는 예산)이 없다면, subdomain이 실용적인 선택입니다.

대규모 국제화

진정으로 분리된 지역 경험 -- 다른 콘텐츠, 다른 팀, 다른 CMS 인스턴스 -- de.example.com 또는 jp.example.com 같은 subdomain이 작동 관점에서 의미를 가질 수 있습니다. 비록 대부분의 경우 example.com/de/가 SEO 관점에서 더 낫다고 주장할 수 있지만요.

사용자 생성 콘텐츠 격리

사용자 생성 콘텐츠 (포럼, 커뮤니티 공간)를 호스트한다면, 그들을 subdomain에 두는 것은 자연스러운 방화벽을 제공합니다. 그 콘텐츠가 스팸 공격이나 품질 문제에 맞닥뜨리면, 피해는 메인 도메인의 품질 신호에 영향을 미치는 대신 subdomain에 포함됩니다.

요소	Subdirectory	Subdomain
링크 에쿼티 통합	✅ 모든 경로에서 공유	❌ 호스트명별로 분리
크롤 예산	✅ 단일 풀	❌ 호스트 간 분할
설정 복잡도	✅ 간단	✅ 간단
기술 스택 유연성	❌ 여러 스택에 reverse proxy 필요	✅ 각 subdomain은 독립적
Google Search Console	✅ 단일 속성	⚠️ 별도 속성 필요
보안 격리	❌ 공유 origin	✅ 별도 origin
사이트 수준 품질 신호	✅ 공유 양의 신호	⚠️ 부모 도메인 신호 상속 가능성 없음
분석 단순성	✅ 같은 속성, 쉬운 추적	⚠️ 크로스 도메인 추적 필요
배포 독립성	❌ 결합된 배포	✅ 독립적 배포

실제 마이그레이션 데이터: 전환 시 무엇이 일어나는가

실제 subdomain-to-subdirectory 마이그레이션에서 본 패턴들을 공유하겠습니다:

SaaS 블로그 마이그레이션

B2B SaaS 회사는 2024년 2분기에 블로그를 blog.company.com에서 company.com/blog로 이동했습니다. 블로그에는 약 400개 글이 있었고 매월 약 15,000 오가닉 세션을 생성하고 있었습니다.

• 1-2주: 트래픽 ~15% 감소 (마이그레이션 중 예상된 변동)
• 3-4주: 사전 마이그레이션 수준으로 회복
• 2-3개월: 꾸준한 상승, 사전 마이그레이션 트래픽의 120%에 도달
• 6개월: 마이그레이션 이전 트래픽의 ~170%에서 안정화

301 리다이렉트는 깔끔했습니다. 모든 blog.company.com/slug는 company.com/blog/slug로 리다이렉트되었습니다. 정규 태그가 업데이트되었습니다. Google Search Console 주소 변경 도구가 사용되었습니다. 그럼에도 처음 2주는 신경 쓰였습니다.

전자상거래 문서 이동

전자상거래 플랫폼은 개발자 문서를 docs.platform.com에서 platform.com/docs로 이동했습니다. 문서에는 자체 외부 백링크가 거의 없었으므로 마이그레이션은 메인 도메인의 권위 상속에 더 관한 것이었습니다.

결과: 문서 페이지의 평균 순위 위치가 60일 내 4.2 순위 개선. 페이지 2에 떠 있던 페이지들이 경쟁이 심한 API 관련 쿼리에서 페이지 1에 나타나기 시작했습니다.

잘못 진행된 것

미디어 회사는 전체 포럼 subdomain을 subdirectory로 이동하려고 시도했습니다. 포럼에는 200만 개 이상의 대부분 낮은 품질의 사용자 콘텐츠 페이지가 있었습니다. 그 모든 것을 메인 도메인의 URL 구조에 병합하는 것은 실제로 메인 사이트의 품질 신호를 해쳤습니다. 30일 내 롤백했습니다.

교훈: 낮은 품질의 콘텐츠를 맹목적으로 메인 도메인의 URL 구조에 병합하지 마세요. 콘텐츠의 품질은 구조만큼 중요합니다.

각 접근 방식의 인프라 패턴

Monolithic 호스팅의 Subdirectory

가장 간단한 접근법입니다. 전체 사이트 -- 마케팅 페이지, 블로그, 문서 -- 단일 애플리케이션 또는 프레임워크에서 실행됩니다.

# 단일 Next.js 애플리케이션
example.com/ → pages/index.tsx
example.com/blog → pages/blog/index.tsx
example.com/docs → pages/docs/index.tsx

이는 더 작은 사이트에 잘 작동합니다. 전체 사이트가 하나의 코드베이스에 있을 수 있는 Next.js 개발 프로젝트에 이 패턴을 자주 사용합니다.

Reverse Proxy의 Subdirectory

이것이 강력한 움직임입니다. 서로 다른 URL 경로에 대해 다양한 애플리케이션을 실행하지만 reverse proxy를 사용하여 하나의 도메인 아래 통합합니다.

# Nginx reverse proxy 설정
server {
    server_name example.com;
    
    # 메인 마케팅 사이트 (Vercel의 Next.js)
    location / {
        proxy_pass https://main-site.vercel.app;
        proxy_set_header Host example.com;
    }
    
    # 블로그 (Netlify의 Astro)
    location /blog {
        proxy_pass https://blog-site.netlify.app;
        proxy_set_header Host example.com;
    }
    
    # 문서 (자체 서버의 Docusaurus)
    location /docs {
        proxy_pass https://docs-internal.example.com;
        proxy_set_header Host example.com;
    }
}

Vercel rewrites, Cloudflare Workers, 또는 Netlify redirects를 사용하면 엣지에서도 이 작업을 할 수 있습니다:

// vercel.json rewrites
{
  "rewrites": [
    {
      "source": "/blog/:path*",
      "destination": "https://blog-site.netlify.app/:path*"
    }
  ]
}

이 패턴은 subdirectory의 SEO 이점을 독립적 배포의 엔지니어링 유연성과 함께 제공합니다. 콘텐츠가 하나의 시스템에 있지만 프론트엔드 아키텍처가 여러 앱에 걸쳐 있는 headless CMS 개발 프로젝트를 접근할 때 우리는 이렇게 합니다.

Subdomain의 DNS 라우팅

인프라 관점에서 가장 간단한 설정:

blog.example.com → CNAME → blog-app.vercel.app
docs.example.com → CNAME → docs-app.netlify.app
app.example.com  → A    → 203.0.113.50

각 subdomain은 완전히 독립적입니다. 설정하기 쉽고, 관리하기 쉽고, 배포하기 쉽습니다. 절충은 순전히 SEO 측면입니다.

Headless CMS와 Subdirectory의 장점

Headless CMS 설정을 실행 중이라면 -- 2026년에는 아마 그럴 겁니다 -- subdirectory 접근법은 현대적 프레임워크가 작동하는 방식과 자연스럽게 정렬됩니다.

Astro, Next.js, 또는 Nuxt와 같은 도구로, CMS (Sanity, Contentful, Strapi, 등)에서 콘텐츠를 가져오고 원하는 모든 URL 경로에서 렌더링할 수 있습니다. 블로그가 subdomain에 있어야 할 기술적 이유는 없습니다.

전형적인 headless 아키텍처:

Contentful (CMS)
    ↓ API
Next.js (Frontend)
    ├── / (마케팅 페이지)
    ├── /blog (CMS 기반 블로그)
    ├── /docs (CMS 기반 문서)
    └── /resources (CMS 기반 리소스)

모든 것이 하나의 도메인 아래에 있습니다. 하나의 배포. 성능 최적화 한 세트. 하나의 도메인 권위 점수.

이 접근법의 아름다움은 headless CMS의 콘텐츠 관리 유연성과 통합 도메인 구조의 SEO 이점을 얻는다는 것입니다. 이는 Social Animal에서 클라이언트를 headless 아키텍처 방향으로 미는 주요 이유 중 하나입니다.

Reverse Proxy 패턴: 양쪽 모두 얻기

많은 중견 기업에서 엔터프라이즈 클라이언트를 위해 가장 자주 사용하는 패턴을 자세히 설명하겠습니다. 이는 통합 SEO와 독립적 배포가 모두 필요한 경우입니다.

아키텍처 개요

Cloudflare (Edge)
    ├── example.com/* → Vercel (Next.js 마케팅 사이트)
    ├── example.com/blog/* → Vercel (Astro 블로그)
    ├── example.com/docs/* → Netlify (Docusaurus)
    └── app.example.com/* → AWS (React SPA - SEO 불필요)

app.example.com은 여전히 subdomain입니다. 의도적입니다 -- 검색 엔진이 인덱스해서는 안 되는 인증된 앱입니다. SEO 주스가 필요한 모든 것은 메인 도메인 아래에 있습니다.

Cloudflare Workers로 구현

// 경로 기반 라우팅을 위한 Cloudflare Worker
export default {
  async fetch(request, env) {
    const url = new URL(request.url);
    
    // /blog 경로를 블로그 origin으로 라우트
    if (url.pathname.startsWith('/blog')) {
      const blogUrl = new URL(request.url);
      blogUrl.hostname = 'blog-origin.example.com';
      return fetch(blogUrl, {
        headers: {
          ...request.headers,
          'X-Forwarded-Host': url.hostname,
        },
      });
    }
    
    // /docs 경로를 문서 origin으로 라우트
    if (url.pathname.startsWith('/docs')) {
      const docsUrl = new URL(request.url);
      docsUrl.hostname = 'docs-origin.example.com';
      return fetch(docsUrl, {
        headers: {
          ...request.headers,
          'X-Forwarded-Host': url.hostname,
        },
      });
    }
    
    // 기본: 메인 마케팅 사이트
    return fetch(request);
  },
};

이는 엣지에서 실행되며 최소 지연시간을 추가합니다 (일반적으로 <5ms), 라우팅에 대한 완전한 제어를 제공합니다. 각 팀은 독립적으로 배포할 수 있으면서 통합 도메인을 검색 엔진에 제시합니다.

주의할 함정

• 자산 경로: 블로그의 CSS, JS, 이미지가 상대 경로를 사용하거나 올바른 subdirectory 접두사에서 제공되는지 확인하세요.
• 후행 슬래시: 일관되게 하세요. /blog와 /blog/를 섞으면 리다이렉트 루프나 중복 콘텐츠 문제가 발생합니다.
• 캐시 헤더: 엣지 프록시가 캐시 헤더를 올바르게 존중하고 통과해야 합니다.
• HTTPS 인증서: 엣지 레이어는 메인 도메인의 유효한 인증서가 필요합니다. 백엔드 origin은 다른 인증서를 사용할 수 있습니다.

순위를 떨어뜨리는 일반적인 실수

실수 #1: 마이그레이션 중 301 리다이렉트 건너뛰기

명백해 보이지만, 이것이 내가 원하는 것보다 더 많이 본 적 있습니다. 모든 단일 이전 URL은 새 위치로 301 리다이렉트가 필요합니다. 302가 아닙니다. 메타 새로고침이 아닙니다. 올바른 301입니다.

실수 #2: Subdomain과 Subdirectory 정규 태그 섞기

blog.example.com/post와 example.com/blog/post 모두 해석되면, 하나 또는 다른 쪽을 가리키는 정규 태그가 필요합니다. 둘 다 정규 태그 없이 살아 있으면 Google이 하나를 선택하는데, 그것이 당신이 원하는 것이 아닐 수도 있습니다.

실수 #3: Google Search Console 마이그레이션 무시

Subdomain에서 subdirectory로 이동할 때, Search Console에서 주소 변경 도구를 사용하세요. 이는 Google에 이동을 명시적으로 알려주고 다시 인덱싱 과정을 가속화합니다.

실수 #4: 낮은 품질의 콘텐츠를 메인 도메인으로 이동

미디어 회사 예제가 보여줬듯이, 낮은 품질 또는 얇은 콘텐츠를 메인 도메인에 통합하면 실제로 해를 끼칠 수 있습니다. 마이그레이션 전 콘텐츠 품질을 감사하세요. 약한 페이지를 가지치기 또는 개선합니다.

실수 #5: 내부 링크 업데이트 안 함

마이그레이션 후, 전체 코드베이스와 CMS에서 이전 URL에 대한 참조를 grep 하세요. 301 리다이렉트되는 이전 subdomain URL을 가리키는 내부 링크는 작동하지만 이상적이 아닙니다. 직접 링크가 항상 리다이렉트 체인보다 낫습니다.

2026년을 위한 의사결정 프레임워크

클라이언트에게 조언할 때 사용하는 프레임워크입니다. 복잡하지 않지만, 작동합니다.

Subdirectory 사용 시:

• 콘텐츠가 오가닉 검색 트래픽을 주도하도록 의도됨
• 콘텐츠는 높은 품질이고 브랜드를 잘 반영함
• 인프라를 관리할 수 있음 (reverse proxy가 필요하더라도)
• SEO는 비즈니스를 위한 주요 성장 채널

Subdomain 사용 시:

• 애플리케이션이 인증 뒤에 있음 (SEO 값 없음)
• 콘텐츠는 사용자 생성이고 잠재적으로 낮은 품질
• 규제 또는 보안 요구 사항이 격리를 요구함
• 콘텐츠가 완전히 다른 대상/언어를 대상으로 함 AND 그 subdomain에 대해 독립적으로 권위를 구축할 리소스가 있음

하이브리드 접근법 (가장 일반적):

• SEO 중요 콘텐츠 → subdirectory (/blog, /docs, /resources)
• 애플리케이션 → subdomain (app., dashboard.)
• 스테이징/개발 → subdomain (staging., preview.)
• 지원/커뮤니티 → 경우별로 평가

확실하지 않으면 subdirectory로 기본 설정하세요. Reverse proxy의 엔지니어링 비용은 일회성 투자입니다. SEO 이점은 시간 경과에 따라 복합됩니다.

사이트에 적절한 아키텍처를 파악하는 데 도움이 필요하신가요? 우리는 headless CMS 및 Next.js 개발 계약 중에 정확히 이러한 종류의 결정을 진행합니다. 가격책정을 확인하거나 구체적인 상황에 대해 이야기하기 위해 직접 연락할 수도 있습니다.

FAQ

Google이 subdomain을 별도 웹사이트로 취급합니까?

정확히는 아니지만 비슷합니다. Google은 subdomain이 Search Console 및 크롤 예산 할당 내에서 별도 호스트로 취급된다고 확인했습니다. Google이 blog.example.com과 example.com 간 관계를 이해하지만, 링크 에쿼티와 품질 신호는 subdirectory 구조 내에서처럼 이들 사이를 흐르지 않습니다.

블로그를 subdomain에서 subdirectory로 마이그레이션할 가치가 있습니까?

대부분의 경우 그렇습니다 -- 특히 오가닉 검색이 의미 있는 트래픽 채널인 경우. 데이터는 일관되게 subdirectory 블로그가 다른 모든 것이 동일한 subdomain 블로그보다 검색에서 더 잘 수행된다고 보여줍니다. 그러나 마이그레이션 자체는 단기 위험 (트래픽 변동 2-4주)을 수반하므로 적절한 301 리다이렉트와 Search Console 마이그레이션으로 신중하게 계획하세요.

Reverse proxy 대신 Vercel rewrites를 사용할 수 있습니까?

절대적으로. Vercel의 vercel.json 또는 next.config.js의 rewrites는 엣지에서 reverse proxy로 기능합니다. 메인 사이트가 이미 Vercel에 있다면 이는 훌륭한 솔루션입니다. /blog 경로를 완전히 별도 애플리케이션으로 라우트할 수 있으며, Google 관점에서는 모두 통합 사이트처럼 보입니다.

Google이 subdomain-to-subdirectory 마이그레이션을 인식하는 데 얼마나 걸립니까?

일반적으로 대부분의 URL이 새 위치에서 다시 인덱스되는 데 2-8주 걸립니다. 더 많은 페이지가 있는 더 큰 사이트는 더 오래 걸립니다. Google Search Console의 주소 변경 도구를 사용하고 업데이트된 사이트맵을 제출하면 이를 가속화할 수 있습니다. 1-2주차에 일시적 순위 하락을 예상한 후 회복과 종종 개선을 따릅니다.

Subdomain이 Core Web Vitals 점수에 영향을 미칩니까?

Core Web Vitals는 origin별 (프로토콜 + 호스트명 + 포트)으로 측정됩니다. 그래서 blog.example.com은 example.com과 완전히 별도의 CWV 점수를 가집니다. 블로그가 빠르지만 메인 사이트가 느린 경우 이점일 수 있습니다. 반대가 true인 경우는 단점입니다. Subdirectory의 경우, 좋은 페이지와 나쁜 페이지 모두 같은 origin의 CWV 평가에 기여합니다.

Subdomain과 subdirectory를 다른 목적으로 모두 사용할 수 있습니까?

이는 실제로 가장 일반적이고 2026년에 권장되는 패턴입니다. SEO 중요 콘텐츠를 subdirectory에 놓으세요 (/blog, /docs, /resources). Subdomain을 애플리케이션, 스테이징 환경, 메인 도메인의 품질 신호와 명시적으로 연관되고 싶지 않은 모든 콘텐츠에 사용하세요. 핵심은 어떤 콘텐츠가 어디로 가는지에 대해 의도적인 것입니다.

Subdomain vs subdirectory 선택이 페이지 속도에 영향을 미칩니까?

본질적으로는 아닙니다. 페이지 속도는 호스팅, 코드 최적화, 자산 전달에 따라 달라집니다 -- URL 구조에는 따라 다르지 않습니다. 그러나 reverse proxy를 통해 제공되는 subdirectory는 프록시 홉에 약간의 지연시간을 추가합니다 (일반적으로 1-10ms). 이는 실제로는 무시할 수 있습니다. 더 큰 페이지 속도 요소는 URL 구조에 관계없이 Astro 같은 적절한 프레임워크를 사용하고 있는지입니다.

2025-2026의 데이터가 subdomain vs subdirectory SEO 성능에 대해 무엇을 말합니까?

여러 대규모 분석이 같은 방향을 가리킵니다. 10,000개 이상의 사이트를 분석한 Ahrefs의 2024년 연구는 콘텐츠 품질과 백링크를 제어했을 때 subdirectory 페이지가 동등한 subdomain 페이지를 60% 더 자주 상위에 랭크했음을 보여줬습니다. HubSpot 자신의 광범위하게 인용되는 subdomain 블로그에서 subdirectory로의 마이그레이션은 오가닉 트래픽의 의미 있는 증가를 초래했습니다. 상관관계가 인과관계는 아니지만, 패턴은 다양한 연구와 사례 연구에 걸쳐 일관되므로 SEO 중심 콘텐츠에는 subdirectory가 더 안전한 기본값입니다.