[SEO] Next.js SEO 최적화 실전 적용기

Dico·2025년 4월 8일
AhrefsCanonicalHreflangJSON-LDMultilingual SEONext.js SEOSSR SEOalternatedynamic sitemapsearch engine optimizationseositemap검색엔진최적화
0

[SEO]

목록 보기
1/5
post-thumbnail

💡 글을 시작하며

이 글은 Next.js 13 버전 Pages Router기반으로 만든 다국어 웹 서비스에 직접 SEO전략들을 적용해보며 검색 결과 개선과정을 정리한 경험 기록입니다.
다양한 검색 엔진이 있지만, 이 글은 Google검색에 초점이 맞춰져 있습니다.
실제 서비스에서 마주한 문제들을 하나씩 해결해가며 가설 세우고, 적용하고, 데이터로 검증하는 과정을 담았습니다.

저 역시도 아직 가설-검증-실패or성공-또 다른 가설..(반복)의 과정을 반복하며 시행착오를 겪는 중이라 여전히 완벽한 정답이 아닐 수 있으니, 혹시 잘못된 부분이 보이거나 더 좋은 방법이 있다면 댓글로 피드백 주시면 감사하겠습니다 🙇‍♀️

SEO가 낯설거나 실무 적용이 막막한 분들께, 이 글이 조금이나마 도움이 되길 바랍니다!

지난날 시도했던 SEO 최적화 전략들

1. SSR 기반 파트너 상세 페이지 컨텐츠 확장

📌 필요한 정보, 충분히 보여주고 있을까?

우리 서비스는 여러 사이트(이하 머천트)를 소개하는 중개형 플랫폼이에요.
각 머천트마다 고유한 상세 페이지가 있었지만, 처음엔 콘텐츠가 너무 빈약하다고 느꼈어요.
단순히 이름, 로고, 링크 몇 개만으로는 유입도 어렵고, 들어온 유저도 금방 나가버릴 것 같았거든요.

마침 마케팅 팀에서 머천트별로 정보를 잘 정리한 Word 파일 자료를 갖고 있었고,
“이걸 그냥 상세 페이지에 넣어보자!”는 게 저희의 출발점이었어요.
한 줄이라도 더 보여주면 검색에도 걸릴 확률이 높아지고, 정보성 페이지로서의 신뢰도도 올라갈 테니까요.

그런데 문제는 양이 너무 많다는 거였죠.
'스크롤이 너무 길어져도 괜찮을까?' 라는 고민도 잠깐 있었지만,
정보 제공이 핵심인 페이지라면, 오히려 길어지는 게 장점이 될 수도 있겠다고 판단했어요.

그래서 선택한 방식은:
1. Word(.docx) 파일을 .mdx 포맷으로 변환할 수 있는 스크립트를 작성하고,
2. 변환된 .mdx 파일을 next-mdx-remote를 사용해 SSR 기반 Component로 렌더링,
3. 그 결과물을 상세 페이지에 그대로 노출시키는 구조로 구성했어요.

덕분에 각 머천트 페이지에는 실제로 유의미한 검색 텍스트들이 다수 포함되게 되었고,
페이지 자체도 "정보가 많은 곳"으로서 역할을 하게 되었습니다!

🎯 검색에서 잘 걸리는 키워드 전략적으로 넣기!

SEO 콘텐츠를 작성할 때 가장 먼저 고민해야 하는 건 사용자가 실제로 어떤 키워드로 검색해서 들어 오는지일텐데요,
저희는 이걸 파악하기 위해 'Ahrefs'라는 SEO 분석 툴을 사용하고 있어요.
유입된 Organic Keyword(자연 검색 키워드) 데이터를 확인할 수 있어서,
해당 키워드를 기반으로 콘텐츠를 조금씩 조금씩 보완해왔어요.

예를 들어, 특정 머천트 페이지에 "서비스명 + 위치", "서비스명 후기" 같은 키워드로 유입이 발생하고 있었다면, 해당 키워드를 페이지 내에 자연스럽게 포함시키는 식이었어요.

그렇지만 꼭 생각한 키워드로만 유입되는 건 아니었어요.
예상하지 못했던 키워드로도 유입이 발생하는 경우가 있었고,
그럴 땐 ‘검색 수요가 있다는 거니까 내용을 더 보완해보자’는 식으로 접근했어요.

무엇보다 중요한 점은, 단순히 키워드를 채워 넣기 보다는
검색 의도에 맞는 정보를 맥락에 맞게 자연스럽게 녹여내는 것이 가장 중요하다는 생각이 듭니다!⭐️
그래야 의미 있는 사용자가 페이지에 머무는 시간(Dwell Time)이 길어지고,
이 역시 컨텐츠의 품질 지표로 작용해 SEO에도 좋은 영향을 주기 때문이에요.

2. JSON-LD 기반 구조화 데이터 적용 (Rich Snippets 노출 목표)

📦 스키마도 종류가 많던데, 뭘 써야 하지?

스키마 적용은 검색 결과를 좀 더 풍부하게 보여주는 것을 목표로 하고 있어요.
구글에서는 스키마를 어떻게 작성해야 하는 지에 대해 공식 가이드라인도 제공하고 있답니다:
👉 Google 검색에서 지원하는 구조화된 데이터 마크업

적용하는 스키마의 type에 따라 검색 결과에서 미리보기 형태로 노출되는 요소들이 달라지기 때문에,
서비스의 성격에 따라 스키마를 선별해서 적용하는 것이 중요하다는 생각이 듭니다.

저희 서비스에서는 아래의 스키마 타입들을 적용했어요:

  • Organization / WebSite:
    브랜드나 사이트 자체에 대한 정보를 검색엔진에 명확히 전달하기 위해

  • BreadcrumbList:
    블로그 콘텐츠나 카테고리 구조가 있는 페이지에 적용해서,
    자연스럽게 사이트 회유(다른 페이지 탐색) 가능성을 높이고,
    시각적으로 검색 결과를 더 풍성하고 신뢰감 있어 보이게 하기 위해

  • FAQPage:
    자주 묻는 질문을 FAQ 형태로 스키마에 포함시켜,
    검색 결과에서 사용자의 궁금증을 미리 풀어주기 위해

🚨 짚고갈 점!
구조화 데이터를 적용했다고 해서, "반드시" 검색 결과에 리치 스니펫이 노출되는 것은 아닙니다.
구글은 구조화 데이터를 단순히 "참고용"으로 활용할 뿐,
실제로 노출할지 여부는 자체 알고리즘의 판단에 따라 결정한다고 해요.

예를 들어 FAQPage 스키마를 넣었더라도,
페이지 콘텐츠의 품질이나 주제의 적절성, 사용자 만족도 등 여러 기준을 종합적으로 고려해
구글이 판단하기에 "리치 스니펫으로 노출할 가치가 있다"고 생각해야지만 실제 검색 결과에 반영됩니다.

그래서 스키마를 넣는 것만으로 끝이 아니라,
페이지 자체의 콘텐츠 품질, 메타 정보, 유저 행동 데이터 등과 함께 총체적으로 관리하는 게 중요합니다💡

🔧 직접 짤까, 라이브러리를 쓸까?

SEO를 개선하면서 Next.js 프로젝트에서 정말 효자같은 라이브러리가 하나 있었는데요, 바로 next-seo입니다.
(이후 내용에서도 종종 등장할 예정이라, 여기서는 간단히만 언급하고 넘어갈게요 👀)

next-seo에서도 JSON-LD 스키마를 위한 컴포넌트를 제공하기 때문에 next-seo를 통해 주입할 지, 아니면 직접 작성을 할 지도 고민이 되었어요.

< next-seo로 삽입하기 >

import { FAQPageJsonLd } from 'next-seo'

<FAQPageJsonLd
  mainEntity={[
    {
      questionName: '이 서비스는 어떻게 이용하나요?',
      acceptedAnswerText: '회원가입 후 로그인하면 다양한 혜택을 이용할 수 있습니다.',
    },
    {
      questionName: '서비스는 무료인가요?',
      acceptedAnswerText: '기본 이용은 무료이며, 일부 프리미엄 기능은 유료입니다.',
    },
  ]}
/>

< 직접 삽입하기 >

※ 구조화 데이터는 <script type="application/ld+json"> 내부에 순수 JSON 문자열로 삽입해야 하므로, React에서는 dangerouslySetInnerHTML을 사용합니다.

const dynamicJsonLdObject = {
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "이 서비스는 어떻게 이용하나요?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "회원가입 후 로그인하면 다양한 혜택을 이용하실 수 있습니다."
      }
    },
    {
      "@type": "Question",
      "name": "서비스는 무료인가요?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "기본적인 이용은 무료이며, 일부 프리미엄 기능은 유료입니다."
      }
    }
  ]
}

return (
  <Head>
    <script
      type="application/ld+json"
      dangerouslySetInnerHTML={{ __html: JSON.stringify(dynamicJsonLdObject) }}
    />
  </Head>
)

실제 서비스에서는 페이지마다 구조화 데이터의 구성도 다르고 조건 분기나 동적 데이터 삽입이 필요한 경우가 많았기 때문에 결국 JSON-LD 코드를 직접 작성해서 _app.tsx에서 주입하는 방식을 선택했습니다.

이렇게 했을 때의 장점은 스키마와 관련된 데이터들을 한 곳에서 관리할 수 있고,
그리고 스키마가 SSR 환경에서 더욱 명확히 크롤러에게 전달 될거라고 기대할 수 있어요.

⁉️ next-seo 를 사용하면 SSR 환경에서 스키마 삽입이 안되나요?

아니에요,
next-seo의 JSON-LD 컴포넌트는 SSR, SSG 환경에서도 <script type="application/ld+json"> 태그로 잘 렌더링됩니다!

다만 동적으로 가져오는 데이터(ex. API 호출 결과로 만든 JSON-LD)를 next-seo 컴포넌트에 넘기면, 렌더링 시점에 따라 CSR이 되어 크롤러가 스키마를 읽지 못하는 문제가 생길 수 있어서 페이지별로 조건 분기나 동적 내용 삽입이 필요한 경우에는 직접 구조화 데이터를 작성하고 주입하는 방식이 제어와 유연성 면에서 더 실용적일 거라고 생각했답니다. 🥸

3. Canonical URL 설정 및 중복 페이지 대응

⚠️ 중복 페이지 문제, 어떻게 해결할까?

앞서 언급했듯이 저희 서비스는 10여개의 언어를 지원하는 다국어 웹사이트를 운영하고 있어요.
하나의 페이지를 다양한 언어로 제공하기 위해, 하나의 번역키(key)에 여러 개의 번역값(value)이 매핑되어 있어서,
사용자가 선택한 locale에 맞는 번역값을 받아와 페이지를 렌더링하게 됩니다.

그런데 페이지 수와 지원언어가 많다 보니, 번역값 입력 작업이 끝나지 않은 페이지들의 경우,
영어페이지가 아니어도 백업(back-up / default) 언어인 영어로 노출이 되고 있었어요.

문제는 여기서부터 발생했어요❗️
구글은 URL이 다르면 다른 페이지로 인식합니다.
그래서 locale이 다른 /en-US/partner/abc 와 /ko-KR/partner/abc를 서로 다른 페이지로 인식하죠.
하지만 미번역 페이지는 영어로 노출되고 있었기 때문에 중복 콘텐츠(Duplicate Content)로 간주되어서 검색 노출에 부정적인 영향을 주고 있었어요.


당장 번역값을 넣을 수 없어도 SEO를 해치는 것만큼은 막아야 했기 때문에!
저희는 Canonical 태그를 설정했습니다.
서로 다른 언어 URL이 있더라도 구글에 "이 페이지의 원본은 이거예요!"라고 대표 URL을 명시적으로 알려주는 방식이죠.
즉, "중복처럼 보여도 중복 페이지가 아닙니다!" 라고 구글에게 알려주는 방법이에요.

Next.js에서는 next-seo를 통해서 Canonical 태그를 간단히 설정할 수 있어요:
👉 next-seo 공식문서 - Canonical 태그

Canonical 태그 설정은 Ahrefs의 언어별 Canonical 구조를 참고했는데요,
다국어 SEO를 고려한 대표적인 성공 사례 중 하나이기도 해서, 실제 운영 중인 사이트를 벤치마킹하는 데 좋은 참고가 되었습니다.

※ ahrefs.com 의 canonical 태그:

4. Multilingual SEO 적용

🌍 다국어 페이지, 구글에 제대로 인식시키려면?

다국어 서비스에서 개발자도구를 열면 위와 같이 설정된 태그들을 어렵지 않게 볼 수 있는데요,
이게 다 뭐하는 태그일까...싶지만, 다국어 페이지를 운영한다면 반드시 설정해줘야 하는 옵션입니다.

하나씩 살펴보면:

  • hreflang={locale}: 서로 다른 언어 버전의 페이지가 동일한 컨텐츠임을 명시하는 태그로, 구글이 사용자의 언어와 지역에 맞는 페이지를 우선적으로 매칭해서 노출
  • hreflang="x-default": 사용자의 언어 설정과 일치하는 페이지가 없을 때 보여줄 기본 페이지를 지정하는 용도
  • rel="alternate": hreflang을 쓸 때 같이 지정되는 속성으로, "이 페이지는 이런 언어 버전도 있어요"라는 의미를 검색엔진에게 전달

이 부분 역시 next-seo가 제공하는 languageAlternate 라는 옵션을 통해 간단히 구현할 수 있어요:

import { NextSeo as Seo } from 'next-seo';

// (...생략) 

const NextSeo = ({ path }: NextSeoProps) => {
  const { i18n } = useTranslation();
  const currentLanguage = i18n.language;
  
   // x-default 값은 사용자의 언어 설정과 일치하는 페이지가 없을 때 
   // 보여줄 기본 언어(en-US) 버전을 지정합니다.  
  const reciprocal = [
    { hrefLang: 'x-default', href: getHrefLang({ path, lang: 'en-US' }) },
  ];

  // 모든 지원 언어에 대한 alternates 생성
  const alternates = supportedLngs.map((lang) => ({
    hrefLang: lang,
    href: getHrefLang({ path, lang }),
  }));

  return (
    <Seo
      canonical={getHrefLang({ path, lang: currentLanguage })}
      languageAlternates={[...reciprocal, ...alternates]}
    />
  );
};

🚩 자주 하는 실수: canonical + hreflang 충돌
canonical이 /en-US/page로 설정되어 있는데, /ko-KR/page에도 canonical이 /en-US/page로 되어 있으면 구글은 "한국어 페이지도 결국 영어 페이지가 대표구나"라고 생각함 → 한국어 페이지 노출 안 됨!

그래서 다국어 페이지에서는 보통 canonical은 자기 자신을 가리키고, hreflang으로 서로 연결하는 게 일반적인 패턴이에요.

5. Sitemap 최적화 및 제출

🗺️ Sitemap은 왜 만들어야 할까?

웹사이트 구조가 복잡하거나, 내부 링크만으로는 도달하기 어려운 페이지가 있다면 검색 엔진이 모든 페이지를 자동으로 찾아내기 어렵다고 해요.
이 때 검색 엔진이 우리 사이트를 더 빠르고 정확하게 인식하도록 도와주는 것이 바로 sitemap.xml!

✅ sitemap의 장점:

  • 더 빠르게 인덱싱할 수 있도록 유도
  • 숨겨진 페이지나 동적으로 생성된 페이지도 누락 없이 포함

lastmod 정보를 포함하면, 업데이트된 페이지를 우선적으로 다시 크롤링하도록 유도할 수 있어요.
즉, sitemap은 단순한 페이지 목록이 아니라, '검색 노출의 효율성을 높여주는 중요한 SEO 도구'랍니다.

🙋🏻‍♀️ 크롤러가 자주 찾아오는 sitemap이란?

결론부터 말하자면, "<lastmod> 값이 자주 갱신되는 sitemap", "실제로 컨텐츠가 자주 바뀌는 URL이 포함된 sitemap" 이라고 해요.

초기에는 sitemap을 수동(manual)으로 관리했어요.
필요할 때마다(예: 새로운 페이지 추가나 삭제 등) sitemap.xml을 생성하는 스크립트를 실행해 XML 파일을 업데이트하고, 그걸 함께 배포하는 방식이었죠.

하지만 운영을 할 수록 수동 업데이트 방식이 점점 비효율적으로 느껴졌어요.
그래서 Next.js에서 제안하는 방식처럼 sitemap.xml을 동적(dynamic) 생성 방식으로 변경했습니다❗️
pages/sitemap.xml.js 파일에서 getServerSideProps()를 활용해 페이지 요청 시점에 실시간으로 sitemap을 생성하고 XML로 응답하는 구조로 개선을 진행했어요.

✅ 동적(dynamic) sitemap 생성 방식의 장점:

  • 페이지가 새로 추가되거나 수정되어도 sitemap이 자동으로 최신 상태를 유지
  • lastmod 값도 서버에서 동적으로 삽입되어 항상 최신 날짜를 반영

특히 lastmod는 검색 엔진이 해당 페이지를 다시 크롤링할 필요가 있는지 판단하는 기준이 되기 때문에, 최신 상태로 유지하는 것이 빠른 인덱싱과 업데이트 반영에 효과적이에요.

🚀 직접 제출 vs. 기다리기

sitemap.xml 페이지를 만들어서 배포해두면, 언젠가는 구글이 알아서 sitemap 경로를 찾아 크롤링하게 되어 있어요 (...그런데 언제쯤? 🙄)
하지만 기다리지 않고 Google Search Console(GSC)에 sitemap을 직접 제출하는 방법도 있죠!

크롤러가 sitemap을 읽어줄 때까지 기다리는 건 반영시기를 예측하기가 어렵지만,
sitemap을 직접 제출하면 역으로 알릴 수 있기 때문에, 크롤러가 더 빠르게 새로운 페이지를 인덱싱할 확률이 높아져요.
또 GSC에서 정확히 몇 개의 URL이 제출되었고, 몇 개가 인덱싱되었는지 상태를 모니터링할 수 있다는 장점도 있어요.

블로그 페이지처럼 개발팀에서 배포하지 않아도 추가될 수 있는 정적 페이지들이 있을 수 있기 때문에
저는 주기적으로 sitemap을 GSC에 제출해서 알려주고 있어요.

6. 페이지 체계/URL 구조 리디자인

📬 URL만 바꿨을 뿐인데 검색 노출이 달라진다고?

저희 서비스의 파트너 상세 페이지는 처음엔 단순한 ID 기반 URL 구조를 가지고 있었어요.
예를 들어, /partners/12/34 같은 형태였죠.
개발 관점에서는 깔끔하고 구조적으로도 정리된 URL이지만, SEO 관점에서는 아무런 의미를 담고 있지 않은 숫자 나열일 뿐이었어요.

그래서 검색 노출 개선을 위해, URL 구조를 다음과 같이 바꾸게 됐습니다:

  • /partners/12/34 ➡️ /partners/velog/12/34

중간에 파트너명(/velog)을 끼워 넣는 구조로 바꾸게 되었는데요, 이유는 단순해요.
검색 결과에 '파트너명'을 직접 노출시키고 싶었기 때문이에요.

🔍 왜 URL을 이렇게 바꾸는 게 더 유리할까?

검색엔진은 URL 안에 포함된 단어도 콘텐츠의 주요 키워드 중 하나로 인식합니다.
따라서 URL 경로에 검색되었으면 하는 브랜드명이나 서비스명 같은 키워드를 포함해두면,
해당 키워드로 검색했을 때 더 잘 노출될 가능성이 높아져요.

또한 사용자의 입장에서도 /partners/chrome/12/34처럼 브랜드명을 포함한 URL이
/partners/12/34보다 어떤 페이지인지 직관적으로 이해하기 쉽기 때문에,
클릭 유도율(CTR)에도 긍정적인 영향을 줄 수 있어요.

물론 이 구조가 반드시 검색 순위를 올려준다고 보장할 순 없지만,
의미 없는 숫자보다 의미 있는 키워드가 들어간 URL이 더 유리하다는 건 SEO에서 오래된 정설 중 하나랍니다 🤫

🧱 h1부터 h6까지, 태그 순서가 SEO에 영향을 줄까?

페이지 구조를 정리하면서 가장 먼저 신경 쓴 부분은 heading 태그의 순서와 위치였어요.

기본적인 원칙은 이렇습니다:

  • ✅ 모든 페이지에는 최소 하나의 h1 태그가 있어야 하며,
    그 h1은 페이지의 가장 상단에, 가장 먼저 나타나야 한다.

h1은 해당 페이지의 핵심 주제를 검색 엔진과 사용자 모두에게 전달하는 역할을 해요.
그리고 검색 엔진은 단순히 태그의 존재 여부뿐 아니라, 페이지 내 시각적 순서도 참고합니다.
즉, 페이지 상단에 h1이 있어야 하고, 실제 사용자 화면에서도 가장 먼저 노출되는 것이 좋아요.

🤔 왜 등장 '순서'가 중요할까?

검색 엔진은 페이지를 위에서 아래로, 왼쪽에서 오른쪽으로 읽습니다.
h1이 아래쪽에 있거나, h2보다 늦게 등장하면 문서의 구조가 혼란스럽다고 인식할 수 있어요.
이는 SEO 신호로도 부정적인 영향을 줄 수 있습니다.

그래서 저는 h1을 페이지마다 반드시 하나씩, 가능한 한 시각적으로도 상단에 배치하도록 했습니다.
그리고 그 아래에는 h2, h3 순서로 내용을 구분하면서 계층 구조를 명확히 했어요.

그래서 저는 h1을 페이지마다 반드시 하나씩,
가능한 한 시각적으로도 상단에 배치하도록 했습니다.
그리고 그 아래에는 h2, h3 순서로 내용을 구분하면서 계층 구조를 명확히 했어요.

🍯 TIP: 구조 분석 더 쉽게 하는 방법
SEO Meta in 1 Click (Chrome 확장 프로그램)에서는 현재 페이지에 사용된 h1~h6 태그의 개수, 순서, 위치를 한눈에 확인할 수 있어요❗️

SEO 전략 적용 전후 비교: 수치로 보는 변화

SEO 개선을 위한 작업들은 오랜 시간에 걸쳐 조금씩 꾸준하게 진행해온 일이었기 때문에 데이터가 충분히 누적되기 전까지는 개선정도를 시작화하기가 어려운 부분이 있었는데요.

하지만 몇 개월의 시간이 지난 지금,
실제로 얼마나 변화가 있었는 지 비교를 위해 본격적으로 SEO 구조 개선을 시작하기 전과 후를 기준으로 해서 현재까지 개선된 총 6개월간의 지표 변화를 알아보겠습니다 📊

Ahrefs/Google Search Console 기반 주요 지표 비교

📊 Google Search Console 검색결과 SEO 개선 전후 3개월 비교

지표개선 전 3개월개선 후 3개월변화 폭해석
클릭 수4921,180🔺 +140% 증가실제 검색 유입 수가 2배 이상 증가
노출 수37,100126,000🔺 +239% 증가검색 결과에 노출된 횟수 3배 이상 증가
CTR1.3%0.9%🔻 -0.4% 하락노출 증가에 비해 클릭률은 낮아짐
평균 순위30.935.4🔻 -4.5 하락전체 키워드 기준 평균 순위는 다소 떨어짐

최근 3개월간의 SEO 개선 결과를 이전 3개월과 비교해본 결과,
검색 클릭 수는 약 2.4배, 검색 노출 수는 약 3.4배 증가했어요.

특히 콘텐츠 확장, 구조화 데이터, sitemap 자동화 등 다양한 개선 작업 이후
검색 노출이 크게 증가했고, 검색 유입 수 또한 눈에 띄게 상승했다는 걸 알 수 있었어요.

반면 CTR(노출된 횟수 중 실제로 클릭된 비율)은 1.3% → 0.9%로 다소 하락했고,
평균 순위도 30.9위에서 35.4위로 소폭 낮아졌지만,
이는 노출 키워드 폭이 넓어졌기 때문에 상대적으로 클릭률이 낮아진 것일 수 있어요.
그리고 이런 경우 '롱테일 키워드' 비중이 증가한 것으로도 해석할 수 있다고 합니다.

📈 ‘롱테일 키워드 비중이 증가했다’는 건 무슨 뜻?

기존에는 주로 브랜드명, 서비스명 등 짧고 인기 있는 키워드 위주로 노출되던 페이지가,
보다 구체적이고 긴 문장형 검색어에서도 노출되기 시작했다는 의미

ex. SEO 로만 유입되던 페이지가 이제는 SEO 올리는 방법, 프론트엔드 SEO 개선 등으로도 유입된다는 뜻

왜 좋은 현상일까?
롱테일 키워드는 경쟁이 약하고 전환율이 높기 때문에 전체 유입량이 자연스럽게 늘어나요.
그리고 컨텐츠가 검색자의 구체적인 질문/의도에 맞게 잘 구성됐다는 증거이기도 합니다 :)

👉 결론적으로, 더 많은 키워드에서 넓은 노출이 일어나고 있고,
CTR과 상위 노출 키워드 비중을 높이는 2단계 최적화가 필요한 시점이라고 볼 수 있어요 🌈

Reference

Google 검색에서 지원하는 구조화된 데이터 마크업
next-seo github
Ahrefs.com
Next.js Sitemap.xml
SEO Meta 익스텐션

profile
Dico
깨진 창문을 내버려 두지 말기
다음 포스트

[SEO] 수치화할 수 있는 개발자가 되자: 프론트엔드를 위한 GA4 / GTM 왕초보 가이드라인

0개의 댓글