2026년 기술 SEO 에이전시: 키워드가 아닌 엔지니어링 측면

2026년에 SEO 에이전시를 고용하는 대부분의 회사는 여전히 키워드, 콘텐츠 캘린더, 백링크 프로필에 대해 생각하고 있습니다. 괜찮습니다. 그런 것들은 중요합니다. 하지만 마케팅 부서보다 엔지니어링 팀에 더 가까운 완전히 다른 종류의 SEO 작업이 있습니다. 제대로 수행된 기술 SEO는 인프라 작업입니다. Googlebot이 React 컴포넌트를 렌더링할 수 없는 이유를 디버깅하는 것입니다. 50,000개의 페이지에 걸쳐 확장되는 내부 링크 시스템을 구축하는 것입니다. 구조화된 데이터가 실제로 페이지에 있는 것에 대해 검색 엔진을 속이지 않도록 하는 것입니다.

Next.js, Astro, 헤드리스 CMS 플랫폼으로 수년간 사이트를 구축해 온 저는 직접 말씀드릴 수 있습니다: 대부분의 "SEO 에이전시"가 제공하는 것과 엔지니어링 관점에서 사이트가 실제로 필요로 하는 것 사이의 격차는 엄청납니다. 이 문서는 2026년 기술 SEO가 실제로 무엇을 의미하는지, 키워드 중심의 SEO와 근본적으로 다른 이유, 그리고 기술 SEO를 한다고 주장하는 에이전시를 평가하는 방법을 설명합니다.

목차

• 2026년 기술 SEO가 실제로 의미하는 것
• 엔지니어링 측면 SEO vs. 키워드 측면 SEO
• 기술 SEO의 핵심 엔지니어링 분야
• JavaScript 렌더링 및 프레임워크별 과제
• 엔지니어링 시스템으로서의 구조화된 데이터
• 크롤 예산 관리 및 사이트 아키텍처
• 핵심 웹 지표: 순위를 매기는 성능 엔지니어링
• AI 검색 가시성: 새로운 기술 개척지
• 기술 SEO 에이전시를 평가하는 방법
• 엔지니어 고용 vs. SEO 컨설턴트 고용 시점
• FAQ

2026년 기술 SEO가 실제로 의미하는 것

기술 SEO는 검색 엔진과 이제는 AI 시스템이 콘텐츠를 크롤링, 렌더링, 인덱싱 및 이해할 수 있도록 웹사이트의 인프라를 최적화하는 실천입니다. 그것이 교과서적 정의입니다. 실제로는 페인트가 아닌 배관 작업을 하고 있다는 뜻입니다.

SEO 커뮤니티에서 널리 인용되는 관찰에 따르면: 2026년의 기술 SEO는 더 이상 이점을 만들지 않습니다. 그것은 불이익을 방지합니다. 페이지 속도, 모바일 사용성, 크롤링 가능성, 인덱싱 기본을 실패하는 사이트는 콘텐츠 품질과 관계없이 어려움을 겪을 것입니다. 약 25%의 웹사이트는 여전히 불량한 내부 링크, robots.txt 오구성, 또는 손상된 사이트 아키텍처로 인한 심각한 크롤링 가능성 문제를 가지고 있습니다.

하지만 여기서 변경된 것은: "검색"의 정의가 분화되었습니다. 사용자는 더 이상 Google에서만 검색하지 않습니다. Perplexity에 질문하고, ChatGPT에 프롬프트를 입력하고, TikTok에서 발견하고, SERP의 AI Overviews에서 직접 답변을 얻습니다. 기술 아키텍처는 동시에 여러 엔드포인트에 데이터를 제공해야 합니다. 그것은 콘텐츠 마케팅 문제가 아니라 엔지니어링 문제입니다.

Google의 John Mueller는 "일관성이 가장 큰 기술 SEO 요소"라고 강조했습니다. 링크는 동일한 URL 버전을 가리켜야 하고, canonical은 탐색과 일치해야 하며, 구조화된 데이터는 보이는 콘텐츠와 일치해야 합니다. 원칙적으로는 간단합니다. 여러 기여자가 있는 큰 동적 사이트에서 유지하기는 매우 어렵습니다.

엔지니어링 측면 SEO vs. 키워드 측면 SEO

이 두 세계 사이에 명확한 경계를 그어봅시다. 다른 기술, 다른 도구, 그리고 솔직히 말해 다른 유형의 사람이 필요합니다.

측면	키워드 측면 SEO	엔지니어링 측면 SEO
주요 기술	콘텐츠 전략, 카피라이팅	웹 개발, 시스템 아키텍처
도구	Ahrefs, SEMrush, Clearscope	Screaming Frog, Chrome DevTools, Lighthouse, 맞춤형 크롤러
전달물	콘텐츠 브리프, 키워드 맵, 편집 일정	Schema 구현, 크롤 지시어, 렌더링 수정, CDN 구성
통합 대상	마케팅 팀, 작가, 소셜 미디어	엔지니어링 팀, DevOps, 플랫폼 설계자
성공 측정	순위, 트래픽, 콘텐츠 참여도	크롤 효율성, 인덱스 범위, CWV 점수, 렌더 완료도
스프린트 참여	보통 없음	개발 스프린트에 포함
전형적인 배경	마케팅, 저널리즘	컴퓨터 과학, 웹 개발

대부분의 회사가 하는 실수는 무엇일까요? 키워드 중심의 에이전시를 고용하면서 렌더링 문제, 빌드 파이프라인 최적화 또는 규모의 구조화된 데이터 구현을 수정할 것으로 예상합니다. 그들은 할 수 없습니다. 그것이 그들의 업무가 아닙니다.

반대로 순수하게 기술적인 SEO 에이전시는 블로그 글을 작성하거나 주제 권한 전략을 개발하지 않을 것입니다. 두 분야 모두 중요합니다. 하지만 그들은 근본적으로 다른 기술입니다.

기술 SEO의 핵심 엔지니어링 분야

기술 SEO는 여러 엔지니어링 세부 분야로 나뉩니다. 마케터가 아닌 개발자에게 설명하는 방식으로 각각을 살펴보겠습니다.

크롤링 가능성 엔지니어링

Googlebot이 페이지에 도달할 수 없으면 다른 어떤 것도 중요하지 않습니다. 크롤링 가능성은 검색 엔진 봇이 인덱싱하려는 모든 페이지를 발견하고 접근할 수 있도록 하고, 인덱싱하지 않으려는 페이지는 접근할 수 없도록 하는 것입니다.

여기에는 다음이 포함됩니다:

• robots.txt 관리 -- 여러 환경을 관리하고, 스테이징 사이트가 프로덕션으로 유출되며, 제3자 도구가 자체 지시어를 주입할 때까지 간단해 보입니다
• XML 사이트맵 생성 -- 콘텐츠 변경에 따라 자동으로 업데이트되는 동적 사이트맵, 콘텐츠 유형별로 적절히 분할, 정확한 lastmod 날짜 (모든 URL에서 오늘 날짜가 아님)
• 내부 링크 아키텍처 -- 고아 페이지가 존재하지 않고 링크 가치가 가장 중요한 페이지로 흐르도록 보장하는 프로그래밍 방식의 시스템
• HTTP 상태 코드 위생 -- 리디렉트 체인 제거, 소프트 404 올바르게 처리 (특히 전자 상거래 인벤토리의 경우), 301/302 리디렉트 올바르게 사용

<!-- 예시: 정확한 lastmod를 가진 동적 XML 사이트맵 -->
<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://example.com/products/widget-pro</loc>
    <lastmod>2026-04-15T08:30:00+00:00</lastmod>
    <changefreq>weekly</changefreq>
    <priority>0.8</priority>
  </url>
</urlset>

인덱싱 제어

모든 것을 인덱싱해야 하는 것은 아닙니다. 더 깨끗한 인덱스는 종종 더 높은 순위를 매깁니다. 이것이 "가지치기" 개념입니다. 의도적으로 저품질 페이지 (태그 페이지, 얇은 아카이브, 패싯 탐색 URL, 오래된 제품)를 제거하거나 차단하여 링크 가치를 고성능 자산에 집중시킵니다.

여기서의 엔지니어링 작업은 다음을 포함합니다:

• 동적 페이지 변형 전체에서 canonical 태그 관리
• 매개변수 기반 URL에 대한 noindex 지시어
• rel=next/prev 또는 로드 더 많기 패턴을 사용한 페이지 매김 처리
• 12개월 이상 0 트래픽인 페이지를 식별하는 정기적인 감사

JavaScript 렌더링 및 프레임워크별 과제

여기서 기술 SEO가 정말 흥미로워집니다. 그리고 여기서 대부분의 전통적인 SEO 에이전시는 완전히 망합니다.

React, Next.js, Vue, Nuxt 또는 Svelte로 구축된 최신 웹 애플리케이션은 기본적인 문제를 만듭니다: 검색 엔진 봇은 콘텐츠를 보기 위해 JavaScript를 실행해야 합니다. Google의 렌더러는 엄청나게 개선되었지만 여전히 2단계 인덱싱 시스템에서 작동합니다. 페이지는 먼저 크롤링되고 (원본 HTML), 그 다음 렌더링을 위해 대기열에 등록됩니다 (JS 실행). 해당 렌더 큐는 지연을 도입하고, JS가 실패하거나 시간이 초과되면 콘텐츠가 단순히 인덱싱되지 않습니다.

JavaScript를 많이 사용하는 사이트에 대한 엔지니어링 중심의 기술 SEO는 다음과 같습니다:

서버 측 렌더링(SSR) vs. 정적 생성

Next.js와 같은 프레임워크는 옵션을 제공합니다: SSR, 정적 사이트 생성(SSG), 증분 정적 재생성(ISR). 각각은 크롤링 가능성에 대해 다른 함의를 가집니다.

// Next.js: 빌드 시간 렌더링을 위한 getStaticProps
// 검색 엔진은 완전히 렌더링된 HTML을 즉시 가져옵니다
export async function getStaticProps() {
  const posts = await fetchBlogPosts();
  return {
    props: { posts },
    revalidate: 3600, // ISR: 1시간마다 재생성
  };
}

Social Animal에서는 가능한 한 정적 생성을 기본값으로 사용합니다. 왜냐하면 봇에게 정확히 필요한 것을 제공하기 때문입니다. 완전한 HTML을 첫 번째 요청에서 제공합니다. 동적 콘텐츠의 경우 ISR은 신선도와 크롤링 가능성 사이의 올바른 균형을 유지합니다.

하이드레이션 문제 및 콘텐츠 가시성

미묘하지만 성가신 문제: 페이지가 서버 측에서 렌더링될 수 있지만 중요한 콘텐츠는 클라이언트 측 하이드레이션 후에만 나타납니다. 가격 표, 제품 사양, 리뷰 -- 이들이 초기 렌더 후 클라이언트 측 API 호출을 통해 로드되면 봇이 놓칠 수 있습니다.

수정은 아키텍처적입니다. 모든 SEO 관련 중요 콘텐츠가 초기 서버 응답에 있는지 확인해야 합니다. 이것은 렌더링 파이프라인과 데이터 가져오기 패턴을 모두 이해해야 하는 엔지니어링 작업입니다.

Astro 및 아일랜드 아키텍처

Astro는 기본적으로 JavaScript가 0을 제공하기 때문에 콘텐츠가 많은 사이트에서 점점 더 인기를 얻고 있습니다. 모든 컴포넌트는 명시적으로 클라이언트 측 상호 작용을 선택하지 않는 한 정적 HTML로 렌더링됩니다. 기술 SEO 관점에서 이것은 거의 이상적입니다. 봇은 아무것도 실행할 필요 없이 완전한 콘텐츠를 가져옵니다.

엔지니어링 시스템으로서의 구조화된 데이터

2026년의 구조화된 데이터 (Schema.org 마크업)는 좋으면 좋은 것이 아닙니다. 이것이 기계와 통신하는 방법입니다. Google의 리치 결과, AI Overviews, ChatGPT, Perplexity, 페이지가 무엇인지 이해해야 하는 다른 모든 시스템.

엔지니어링 과제는 단일 페이지에 JSON-LD 블록을 추가하는 것이 아닙니다. 수천 개의 페이지에 걸쳐 정확하고 일관된 구조화된 데이터를 생성하는 시스템을 구축하고, 페이지에 실제로 있는 것에 대해 검증하고, 콘텐츠 변경에 따라 자동으로 업데이트하는 것입니다.

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Widget Pro",
  "description": "대규모 처리를 위한 엔터프라이즈급 위젯",
  "offers": {
    "@type": "Offer",
    "price": "299.00",
    "priceCurrency": "USD",
    "availability": "https://schema.org/InStock",
    "priceValidUntil": "2026-12-31"
  },
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.7",
    "reviewCount": "342"
  }
}

함정은 무엇입니까? 보이는 콘텐츠와 일치하지 않는 구조화된 데이터입니다. JSON-LD가 제품 비용이 $299라고 하지만 페이지에 $349가 표시되면 구조화된 데이터 위반입니다. 규모가 커지면 이러한 불일치는 페이지를 렌더링하는 것과 동일한 데이터 파이프라인에 스키마 생성을 구축하지 않는 한 계속 발생합니다.

헤드리스 CMS 아키텍처의 경우, 이는 페이지를 제공하는 것과 동일한 콘텐츠 API에서 구조화된 데이터를 생성하는 것을 의미합니다. 하나의 신뢰할 수 있는 출처입니다. 드리프트가 없습니다.

크롤 예산 관리 및 사이트 아키텍처

크롤 예산 -- Googlebot이 주어진 기간 동안 사이트에서 크롤링할 페이지의 수 -- 대규모 사이트 (10,000개 이상의 페이지)에 가장 중요합니다. 하지만 더 작은 사이트도 효율적인 크롤 패턴으로부터 이점을 얻습니다.

엔지니어링 측면의 크롤 예산 최적화는 다음을 포함합니다:

• 크롤 함정 제거 -- 무한 달력 위젯, 수백만 개의 URL 조합을 생성하는 패싯 탐색, 세션 기반 URL
• 서버 응답 시간 -- Googlebot은 더 빠른 서버에서 더 빠르게 크롤링합니다. 200ms TTFB 대 2s TTFB는 세션당 훨씬 더 많은 페이지가 크롤링됨을 의미합니다
• 로그 파일 분석 -- 실제 서버 로그를 구문 분석하여 Googlebot이 어떤 페이지를 방문하고, 얼마나 자주, 어떤 상태 코드가 발생하는지 확인

# 빠른 로그 분석: Googlebot이 가장 많이 방문하는 페이지는?
grep "Googlebot" access.log | awk '{print $7}' | sort | uniq -c | sort -rn | head -20

이것은 시스템 작업입니다. 서버 인프라에 대한 접근이 필요하고, CDN 캐싱 동작을 이해해야 하며, 큰 로그 파일을 읽고 분석할 수 있어야 합니다. 대부분의 SEO 컨설턴트는 이를 외주하거나 완전히 건너뜁니다.

핵심 웹 지표: 순위를 매기는 성능 엔지니어링

Google의 핵심 웹 지표 -- 가장 큰 콘텐츠풀 페인트 (LCP), 상호 작용을 다음 페인트로 (INP), 누적 레이아웃 변경 (CLS) -- 는 순위 요소입니다. 완전히. 2026년에 INP는 첫 입력 지연을 완전히 대체했으며, 모든 상호 작용을 측정하지 않고 첫 번째 상호 작용만 측정하기 때문에 최적화하기가 더 어렵습니다.

지표	양호	개선 필요	불량
LCP	≤ 2.5s	2.5s - 4.0s	> 4.0s
INP	≤ 200ms	200ms - 500ms	> 500ms
CLS	≤ 0.1	0.1 - 0.25	> 0.25

이들을 최적화하는 것은 전통적인 의미의 SEO 작업이 아닙니다. 이것은 성능 엔지니어링입니다:

• LCP: 이미지 최적화 (WebP/AVIF, 적절한 크기 조정, 프리로드 힌트), 글꼴 로딩 전략, 서버 측 렌더링, CDN 구성
• INP: 긴 JavaScript 작업 분해, requestIdleCallback 사용, 이벤트 핸들러 최적화, 메인 스레드 차단 감소
• CLS: 이미지/임베드에 명시적 치수, 글꼴 표시 전략, 폴드 위에 동적 콘텐츠 주입 방지

이곳이 실제 개발자를 고용하거나 개발 업체 (예: Social Animal)와 파트너십을 맺은 기술 SEO 에이전시가 단지 보고서를 생성하는 것과 확실한 차이를 만들 수 있는 곳입니다.

AI 검색 가시성: 새로운 기술 개척지

2026년의 현실은 대부분의 에이전시가 여전히 따라잡고 있는 것입니다: 사이트는 Googlebot에 의해서만 크롤링되지 않습니다. OpenAI, Anthropic, Perplexity 및 기타 AI 시스템이 콘텐츠를 스크랩하고, 인용하고, 종합합니다.

Onely 및 다른 기술 에이전시가 지적했듯이, 기술 회사의 AI 검색 최적화는 콘텐츠 마케팅 추가 항목이 아니라 엔지니어링 분야입니다. 이것은 다음을 요구합니다:

• 구조화된 데이터 생태계 콘텐츠를 기계 추출 가능하게 만드는
• Robots.txt 및 AI 봇 지시어 -- AI 크롤러가 접근할 수 있는지 결정 (GPTBot, ClaudeBot, PerplexityBot 등)
• 콘텐츠 아키텍처 AI 시스템이 개별 사실과 주장을 쉽게 추출하고 속성할 수 있게 하는
• 크로스 플랫폼 인용 모니터링 -- AI 시스템이 언제 어디서 콘텐츠를 인용하는지 추적

# robots.txt - 선택적 AI 봇 접근
User-agent: GPTBot
Allow: /blog/
Allow: /docs/
Disallow: /pricing/

User-agent: ClaudeBot
Allow: /

User-agent: PerplexityBot
Allow: /

이것은 거버넌스 작업입니다. 사이트를 인간 방문자의 목적지가 아닌 분산 웹의 데이터 소스로 관리하고 있습니다.

기술 SEO 에이전시를 평가하는 방법

자신을 "기술적"이라고 부르는 모든 에이전시가 실제로 그렇지는 않습니다. 차이를 알 수 있는 방법은 다음과 같습니다:

위험 신호

• 전달물이 주로 키워드 보고서 및 콘텐츠 권장 사항입니다
• Googlebot이 JavaScript를 렌더링하는 방식을 설명할 수 없습니다
• 기술 스택, CI/CD 파이프라인 또는 호스팅 설정에 대해 묻지 않습니다
• 팀이 엔지니어링 배경이 없는 마케터로만 구성되어 있습니다
• 코드베이스 또는 서버 로그에 접근하지 않고 "수정"을 제안합니다

긍정 신호

• Google Search Console, 서버 로그, 스테이징 환경에 대한 접근을 원합니다
• 스프린트 사이클 내에서 작업할 수 있고 풀 요청을 제출할 수 있습니다
• 프레임워크 (Next.js, Astro, Nuxt) 및 그 SEO 영향을 이해합니다
• 키워드를 언급하기 전에 렌더링, 인덱싱 및 크롤 효율성에 대해 이야기합니다
• 순위가 아닌 크롤 통계 및 인덱스 커버리지로 성공을 측정합니다

Onely와 같은 에이전시는 기술 SEO 작업이 기능 개발과 함께 살도록 하는 스프린트 내장 접근 방식을 개척했습니다. 그것이 엔지니어링 팀에게 실제로 작동하는 모델입니다. "기술 SEO 에이전시"가 코드 리뷰에 참여할 수 없다면, 그들은 실제로 기술적이지 않습니다.

엔지니어 고용 vs. SEO 컨설턴트 고용 시점

여기 제 솔직한 생각입니다: 사이트가 최신 프레임워크에 구축되어 있고 인덱싱 문제, 렌더링 문제 또는 불량한 핵심 웹 지표를 경험하고 있다면, SEO를 이해하는 엔지니어가 필요합니다. SEO에 손을 담그는 SEO 컨설턴트가 아닙니다.

대부분의 중대형 회사에 이상적인 설정:

1. 기술 SEO 전략가 감사, 우선 순위 지정, 요구 사항 정의
2. 구현하는 개발자 기존 코드베이스 내의 요구 사항
3. 지속적인 모니터링 자동화된 크롤, 로그 분석, CWV 추적

기술 SEO를 이해하는 회사 내 개발자가 없다면, 에이전시와 함께 일하는 것이 두 진영을 모두 고용하는 오버헤드 없이 그 격차를 채웁니다 (예: Social Animal).

최악의 시나리오는 무엇입니까? SEO 컨설턴트에게 월 $15,000를 지불하는 것. 모호하고, 비현실적이거나, 아키텍처와 호환되지 않는 권장 사항이 있는 50페이지 감사 문서를 받습니다. 나는 이것이 내가 좋아하는 것보다 많이 발생하는 것을 보았습니다.

FAQ

기술 SEO와 일반 SEO의 차이점은 무엇입니까?

일반 (또는 "전통적") SEO는 일반적으로 콘텐츠 최적화, 키워드 타겟팅 및 백링크 획득에 중점을 둡니다. 기술 SEO는 인프라에 중점을 둡니다: 크롤링 가능성, 인덱싱, 렌더링, 사이트 속도, 구조화된 데이터, 아키텍처. 좋은 기사를 작성하는 것과 서버가 실제로 검색 엔진에 제공하는지 확인하는 것의 차이를 생각해 보세요.

별도의 기술 SEO 에이전시가 필요하거나 현재 에이전시가 처리할 수 있습니까?

현재 에이전시의 능력에 따라 다릅니다. 팀에 서버 로그를 읽고, 렌더링 문제를 진단하고, 코드 변경을 제출할 수 있는 개발자가 포함되어 있다면 괜찮을 수 있습니다. 배경이 주로 콘텐츠 및 링크 빌딩인 경우 전문가가 필요할 가능성이 높습니다. 많은 회사는 두 에이전시를 사용합니다. 하나는 콘텐츠 전략용, 하나는 기술 구현용입니다.

2026년에 기술 SEO 에이전시의 비용은 얼마입니까?

가격은 매우 다양합니다. 부티크 기술 SEO 컨설턴트는 월 $3,000-$10,000을 청구합니다. Onely 또는 SALT.agency와 같은 특화된 에이전시는 일반적으로 진행 중인 약정에 대해 월 $8,000-$20,000부터 시작합니다. 더 큰 에이전시의 엔터프라이즈 레벨 기술 SEO 프로그램은 월 $30,000을 초과할 수 있습니다. 프로젝트 기반 감사는 일반적으로 사이트 복잡도에 따라 $5,000-$25,000입니다.

AI 검색이 인수하고 있는데 기술 SEO가 여전히 중요합니까?

이전보다 더 중요합니다. AI 시스템은 Google처럼 콘텐츠를 크롤링하고 이해해야 합니다. 특히 구체적인 사실과 주장을 추출하려고 하므로 더욱 그렇습니다. 구조화된 데이터, 깨끗한 아키텍처, 적절한 크롤 지시어는 AI 검색 가시성의 기초입니다. 이들 없이는 AI 시스템이 접근할 수 없거나 구문 분석할 수 없는 것을 인용할 수 없습니다.

Next.js 또는 React와 같은 JavaScript 프레임워크의 가장 일반적인 기술 SEO 문제는 무엇입니까?

큰 문제들: 클라이언트 측에만 렌더링되는 콘텐츠 (봇의 첫 크롤에서 보이지 않음), 서버 렌더링 콘텐츠가 클라이언트 렌더링 콘텐츠와 다른 하이드레이션 불일치, 봇이 따를 수 없는 클라이언트 측 라우팅, 페이지 로드 후 동적으로 설정되므로 누락되거나 잘못된 메타 태그. 이 모두는 일반적인 SEO 조언이 아닌 프레임워크 특정 솔루션이 필요합니다.

기술 SEO 개선이 정말 수익을 영향을 미칠 수 있습니까?

절대. B2B 회사의 경우 유기 검색은 업계 벤치마크에 따라 대략 44.6%의 수익을 유도합니다. 기술적 문제로 인해 페이지의 10%만 적절히 인덱싱되지 않으면 상당한 돈을 테이블에 남겨두고 있습니다. 렌더링 문제 수정 후 인덱스 영역에서 수천 개의 페이지를 복구한 클라이언트를 봤고 몇 주 내에 30-60% 트래픽 증가에 해당합니다.

기술 SEO와 핵심 웹 지표의 관계는 무엇입니까?

핵심 웹 지표 (LCP, INP, CLS)는 특히 사용자 경험 성능에 중점을 두는 기술 SEO의 하위 집합입니다. 그들은 확인된 순위 신호입니다. 이들을 최적화하려면 진정한 엔지니어링 작업이 필요합니다. 이미지 최적화 (WebP/AVIF, 적절한 크기 조정), JavaScript 프로파일링, 레이아웃 안정성 수정, 서버 성능 튜닝. 콘텐츠 중심의 SEO 에이전시는 일반적으로 이러한 메트릭을 이동할 수 없습니다. 개발자가 필요합니다.