AI로 쓴 글도 검색에 노출될까요? 블로그 운영 사례로 살펴보기

"AI로 쓴 글은 구글이 패널티를 준다", "AI 콘텐츠는 검색 순위에서 밀린다"

Google은 AI로 작성했다는 이유만으로 모든 글을 검색에서 불리하게 취급한다고 안내하지 않습니다. 그렇다고 AI로 쓴 글이 항상 잘 노출된다는 뜻도 아닙니다.

SEO는 검색엔진이 콘텐츠를 찾고 이해하도록 개선하는 작업입니다. 이 글에서는 2026년 3월에 기록한 블로그 개편 경험과 검색 성과를 살펴봅니다. 이후 바뀐 기술 안내는 2026년 10월 4일 기준으로 보완했습니다. 여러 작업을 동시에 했으므로 어느 하나가 성장을 만들었다고 단정하지는 않겠습니다.

먼저 노출과 클릭을 구분하기

검색 결과에 글이 표시된 횟수가 노출, 그 결과를 눌러 사이트로 온 횟수가 클릭입니다. 세션은 분석 도구에서 묶은 방문 활동 단위이며 사람 수나 클릭 수와 같지 않습니다.

다음은 계산 연습용 가상 값입니다. 실제 블로그 수치가 아닙니다.

클릭률은 클릭 ÷ 노출 × 100입니다. 계산기로 20 ÷ 1000 × 100과 30 ÷ 3000 × 100을 확인해 봅니다. 노출은 세 배가 되었지만 클릭은 20회에서 30회로 50% 늘었고 클릭률은 낮아졌습니다. 방문자가 세 배가 되었다고 말할 수는 없습니다.

노출이 0이면 클릭률을 이 식으로 나눠 계산하지 않고 “계산하지 않음”으로 적습니다.

이후 클릭이 60회였다면 클릭률은 60 ÷ 3000 × 100 = 2%로 이전과 같습니다. 다른 답이 나왔다면 분모에 방문자 수 대신 노출 수를 넣었는지 확인합니다. Search Console 지표 설명

한 번 더 계산해 보겠습니다. 노출 2,000회와 클릭 50회라면 클릭률은 50 ÷ 2000 × 100 = 2.5%입니다. 앞의 표와 다른 숫자로도 계산할 수 있으면 노출과 클릭을 구분한 것입니다.

AI 블로그는 어떻게 시작했나요?

지금 보고 계시는 제 블로그(digitalmarketer.co.kr)는 2021년 무렵부터 운영해온 개인 블로그입니다. 원래는 Jekyll(마크다운 문서를 HTML 웹페이지로 만드는 정적 사이트 생성기)로 만들어서 GitHub Pages에 배포하고 있었습니다.

당시 제가 운영하던 구성에서 불편했던 점은 다음과 같습니다. Jekyll을 쓰면 반드시 생기는 문제나 검색 노출이 불가능하다는 뜻은 아닙니다.

• 글을 쓸 때마다 마크다운 파일을 직접 작성하고, 파일명 규칙을 지켜야 했습니다
• SEO 메타데이터(title, description, og 태그 등)를 매번 수동으로 입력해야 했습니다
• 사이트 디자인을 수정하려면 Ruby 환경 세팅부터 해야 했습니다
• 유지보수가 번거로워서 점점 글을 안 쓰게 되었습니다

결과적으로 블로그는 거의 방치 상태가 되었고, 2026년 1월까지 검색 트래픽은 사실상 0에 가까웠습니다. 당시에는 검색으로 들어오는 방문이 드물었습니다.

AI 바이브코딩으로 블로그를 다시 만들면 어떻게 되나요?

2025년 12월, AI 코딩 도구(Claude Code)를 활용해서 블로그를 Next.js 기반의 풀스택 웹앱으로 완전히 새로 만들었습니다. 자연어로 요구를 전달하고 AI가 작성한 코드를 확인하며 만드는 방식인 '바이브코딩'을 활용했습니다. Next.js는 웹앱을 만드는 개발 도구이며, 검색 노출을 위한 필수 선택은 아닙니다.

아래는 2025년 12월 개편 당시의 변화입니다. 개발 용어를 모두 익힐 필요는 없습니다. 제 운영 기록으로 읽고, 자기 글 점검은 뒤의 실습에서 시작하면 됩니다. 메타데이터는 본문 외에 페이지의 제목과 설명 등을 담은 정보입니다. 2026년 10월 현재 글 원본은 다시 마크다운 파일로 관리하므로 관리자 에디터와 DB 설명을 현재 설치 절차로 따라 하면 안 됩니다.

그리고 전환 후 올린 글의 상당수는 AI를 활용해서 작성하고 있습니다. 주제 기획, 목차와 본문 초안에 AI를 쓰고, 사실 확인과 편집은 제가 맡는 방식입니다.

당시 그래프에서 무엇을 확인할 수 있나요?

아래는 당시 Google Search Console에서 가져와 게시한 그래프입니다. Search Console은 사이트의 검색 노출과 클릭, 색인 상태를 확인하는 무료 도구입니다. 색인은 Google이 페이지를 검색에 사용할 정보로 저장하는 과정입니다.

2026년 1월까지 낮았던 그래프가 2월 후반부터 올라갔습니다. 원래 운영 기록에는 하루 검색 노출이 3,000건을 넘었다고 적었습니다. 다만 이 캡처에는 세로축과 지표 이름이 없어서 그림만으로 그 일일 수치를 다시 읽을 수는 없습니다.

이 기간에 올린 글의 대부분은 AI를 활용했습니다. 이 기록은 AI를 활용한 사이트에서도 검색 노출이 늘어날 수 있다는 사례입니다. 글 발행, 주제와 사이트 개편이 함께 달라졌으므로 AI나 특정 SEO 설정의 효과만 분리한 실험은 아닙니다.

AI 콘텐츠를 두고 Google이 밝힌 공식 입장

Google은 AI 도구 사용 자체보다 콘텐츠의 목적과 유용성을 봅니다. 순위를 조작하려고 자동화를 사용하는 것은 정책 위반이 될 수 있습니다. 반대로 적절한 AI 활용 자체가 금지되는 것은 아닙니다. Google의 AI 콘텐츠 안내

현재 안내도 사용자에게 가치를 더하지 않는 페이지를 대량 생성하면 스팸 정책에 위배될 수 있다고 설명합니다. 본문뿐 아니라 제목, 설명과 이미지 대체 문구도 사람이 확인해야 합니다. 유용하다고 판단한 글도 반드시 상위에 노출되는 것은 아닙니다. 생성형 AI 콘텐츠 지침

E-E-A-T(경험, 전문성, 권위와 신뢰)는 콘텐츠를 평가할 때 살펴볼 관점입니다. 하나의 점수나 특정 순위 요소 자체는 아닙니다. 특히 신뢰가 중요하며, 아래 표의 항목을 채웠다고 검색 순위가 보장되지는 않습니다. Google의 유용한 콘텐츠 설명

실제로 하지 않은 경험이나 확인하지 않은 숫자를 AI에게 만들어 넣도록 해서는 안 됩니다. 출처를 붙이는 것과 그 내용을 직접 확인하는 것도 구분해야 합니다.

AI 콘텐츠 + SEO : 실제로 한 작업들

검색 성과가 변한 동안 아래 작업도 진행했습니다. 기술 설정은 검색엔진의 접근과 이해를 도울 수 있지만, 이 기록만으로 어떤 작업이 얼마만큼 기여했는지는 알 수 없습니다.

준이아빠블로그에 실제로 수행했던 SEO 작업을 공개합니다. 당시 구현 기록을 설명하는 목록이며 모든 사이트에 일괄 적용하는 필수 작업표는 아닙니다. 처음이라면 뒤의 “내 글 한 편에서 먼저 확인하기”부터 진행합니다.

1. Google Search Console 연결 및 소유권 인증

가장 먼저 한 일은 Google Search Console에 사이트를 등록하고 소유권을 인증한 것입니다. Google 검색에 나오기 위해 Search Console 가입이 필수인 것은 아닙니다. 소유권 인증은 해당 사이트의 데이터와 관리 기능을 이용하기 위한 절차입니다. Search Console 소개

저는 사이트의 <head>에 인증 메타 태그를 추가했습니다. 인증 방식은 등록하는 속성 종류와 사이트 환경에 따라 다르므로 자신의 화면에 안내된 방법을 사용합니다.

2. robots.txt 설정

검색엔진 봇(크롤러)에게 "이 사이트에서 어떤 페이지를 봐도 되고, 어떤 페이지는 보지 마세요"라고 알려주는 파일입니다.

당시에는 공개 페이지를 허용하고 /admin/, /api/의 크롤링을 막는 설정을 설명했습니다. 현재 준이아빠블로그의 robots.txt 구성은 공개 경로를 허용하고 사이트맵을 안내합니다. 기존 사이트에 차단 규칙을 그대로 복사하기 전에 실제 공개 범위를 확인해야 합니다.

robots.txt는 로그인이나 접근 권한을 대신하지 않습니다. 차단된 주소도 다른 곳에 있는 링크로 발견되어 검색에 나타날 수 있으며, 검색에서 빼려는 페이지에는 별도의 색인 제어가 필요합니다. 비공개 자료는 인증으로 보호해야 합니다. robots.txt의 범위

3. 사이트맵 주제별 인덱스 구조로 개편

사이트맵은 "이 사이트에 어떤 페이지들이 있는지" 검색엔진에게 알려주는 목록입니다.

처음에는 모든 페이지를 하나의 사이트맵에 넣었지만, 콘텐츠가 늘어나면서 주제별로 사이트맵을 분리했습니다.

현재 원본의 경로는 다음과 같습니다. 다른 사이트는 경로와 분리 방식이 다를 수 있습니다.

• /sitemap.xml: 하위 사이트맵을 연결하는 인덱스
• /sitemap/0.xml: 인사이트 글
• /sitemap/1.xml: 클래스와 코스 등 공개 페이지

Google은 priority와 changefreq 값을 사용하지 않습니다. 준이아빠블로그의 현재 코드에는 두 값이 남아 있지만, 값의 크기를 올린다고 검색 순위가 높아지지는 않습니다. lastmod는 실제 중요한 수정일을 정확히 반영해야 합니다. 사이트맵 제출도 수집이나 색인을 보장하지는 않습니다. 사이트맵 공식 설명

4. 구조화된 데이터(JSON-LD) 스키마 적용

구조화된 데이터는 검색엔진에게 "이 페이지가 어떤 종류의 콘텐츠인지" 알려주는 정보입니다. JSON-LD는 이 정보를 웹페이지에 넣는 형식이고, 스키마는 제목이나 작성자 같은 항목을 어떤 이름으로 적을지 정한 규칙입니다.

처음에는 BlogPosting 타입을 사용했다가, 콘텐츠 성격에 더 맞는 Article 타입으로 변경하기도 했습니다. BlogPosting도 Google의 Article 지원 유형에 포함되므로 Article로 이름을 바꿨다는 이유만으로 더 유리하다고 할 수는 없습니다. Article 구조화 데이터 안내

위 표는 당시 구현 기록입니다. Google은 2026년 5월 7일부터 FAQ 리치 결과를 표시하지 않는다고 안내했습니다. FAQPage를 추가하면 검색 결과에 문답이 펼쳐진다는 설명은 현재 적용되지 않습니다. 본문의 문답이 사람에게 유용한지는 별도로 판단합니다. Google 변경 기록

5. SEO 메타데이터 자동 생성 시스템

모든 글에 아래 메타데이터를 체계적으로 관리합니다.

• title 태그 : 페이지 제목이며 검색 제목을 만드는 데 쓰이는 정보
• meta description : 페이지 요약이며 검색 설명에 사용될 수 있는 정보
• og:title, og:description, og:image : SNS 공유 시 표시되는 정보
• canonical URL : 비슷한 페이지 중 대표로 삼기를 원하는 URL 표시

이 메타데이터를 매번 수동으로 작성하면 빠뜨리기 쉽습니다. 준이아빠블로그에서는 AI가 글 내용을 기반으로 메타데이터 초안을 자동 생성하고, 필요시 제가 수동으로 보정하는 방식을 사용합니다.

Google이 검색 제목과 설명을 항상 입력한 그대로 표시하지는 않습니다. 본문과 맞는 제목과 설명을 작성한 뒤 실제 표시를 확인합니다.

6. 구 URL 301 리다이렉트

Jekyll 시절의 URL 구조와 Next.js 전환 후의 URL 구조가 달라졌기 때문에, 기존 URL로 들어오는 방문자가 404 오류를 만나지 않도록 301 리다이렉트(영구 이동)를 설정했습니다.

기존 글과 대응하는 새 글로 직접 연결해야 합니다. 관련 없는 모든 주소를 홈으로 보내는 방식은 피합니다. 이전 과정에서 검색 노출은 일시적으로 달라질 수 있으며 기존 순위의 즉시 유지를 보장하지는 않습니다. Google의 사이트 이전 안내

7. SSG/ISR 하이브리드 렌더링 전환

기존에는 모든 페이지를 서버에서 실시간으로 생성(Server-Side Rendering)했지만, SSG(Static Site Generation) + ISR(Incremental Static Regeneration) 방식으로 전환했습니다.

SSG는 HTML을 미리 만들고, ISR은 미리 만든 페이지를 정한 조건에서 다시 생성하는 방식입니다. 당시 저는 로딩과 운영 방식을 개선하려고 적용했습니다. 검색엔진이 본문을 읽을 수 있고 사용자가 편하게 이용하는지가 중요하며 이 기술 이름 자체가 순위를 높여 주지는 않습니다. Google의 페이지 경험 안내

"AI로 쓰면 SEO에 불리하다"는 오해는 왜 퍼졌을까요?

이 오해가 퍼진 데는 나름의 이유가 있습니다.

이유 1 : AI 초창기의 저품질 콘텐츠 범람

ChatGPT가 처음 나왔을 때, 많은 사람들이 AI에게 "이 주제로 블로그 글 써줘"라고만 하고, 검토 없이 그대로 발행했습니다. 이런 글들은 내용이 피상적이고, 팩트 오류가 있고, 어디서나 볼 수 있는 뻔한 내용이었습니다.

검색 순위가 내려갔다면 내용의 유용성과 정책 위반, 색인 상태 등 여러 원인을 살펴봐야 합니다. AI를 썼다는 사실이나 탐지 도구 점수만으로 하락 원인을 확정할 수는 없습니다.

이유 2 : Google의 "Helpful Content Update" 오해

2022년과 2023년에 Google이 시행한 Helpful Content Update 이후, "AI 콘텐츠를 타겟으로 한 업데이트"라는 해석이 퍼졌습니다. 하지만 Google은 이 업데이트의 목적이 "사용자에게 도움이 되지 않는 콘텐츠를 걸러내는 것"이라고 명시했습니다. AI 여부가 기준이 아닙니다.

이유 3 : AI 탐지 점수와 검색 평가의 혼동

AI 작성 여부를 추정하는 도구의 점수는 Google 검색 순위 점수가 아닙니다. Google 내부에서 어떤 신호를 쓰는지 전부 알 수 없으므로 “AI 탐지를 전혀 사용하지 않는다”라고도 단정하지 않습니다. 공개된 지침과 실제 페이지의 문제를 기준으로 판단합니다.

AI 콘텐츠로 SEO 성과를 내는 방법

아래 원칙은 콘텐츠를 개선하는 데 도움이 되지만 검색 성과를 보장하는 공식은 아닙니다.

원칙 1 : AI 초안을 그대로 발행하지 마세요

AI가 만든 초안은 말 그대로 초안입니다. 아래 과정을 거쳐야 합니다.

• 팩트체크 : AI는 틀린 정보를 자신 있게 말하는 경우가 있습니다. 특히 숫자, 날짜, 고유명사는 공식 자료와 대조합니다
• 구체성 추가 : "~하면 좋습니다" 같은 뻔한 조언 대신, 실제 사례나 구체적 수치를 추가합니다
• 관점 추가 : AI의 중립적인 서술에 자신의 경험이나 의견을 더합니다

준이아빠블로그도 동일한 과정을 거칩니다. 예를 들어 웹사이트 이용을 분석하는 Google Analytics 4(GA4)의 API 할당량을 다루는 글을 쓸 때, AI의 초안에 있던 "Core Reporting API"라는 이전 Universal Analytics(UA)의 용어를 팩트체크를 거쳐 "Google Analytics Data API v1"로 수정했습니다. API는 프로그램이 분석 자료를 요청하는 통로입니다. 표준 속성의 Core 토큰 한도인 속성당 시간당 40,000개와 하루 200,000개를 공식 문서에서 확인해 반영했습니다. 여기서 토큰은 API 요청이 소모하는 할당량 단위로, AI가 문장을 처리하는 토큰과 다른 개념입니다. 요청 한 번이 토큰 한 개와 같은 뜻은 아니며 다른 종류의 제한도 함께 적용됩니다. Data API 할당량

원칙 2 : 검색 의도에 맞는 주제를 선정하세요

검색 유입을 목표로 한다면 사람들이 어떤 표현으로 질문하는지 확인합니다. 검색 수요가 적은 글도 기존 고객이나 학습자에게 필요한 자료일 수 있으므로 검색량만으로 가치를 판단하지는 않습니다.

그렇다면 AI로 작성한 글이 실제 검색 트래픽에 어떤 영향을 미칠까요? 준이아빠블로그에서는 Google Search Console의 검색어 데이터를 분석해서, 사람들이 실제로 검색하는 키워드와 현업에서 궁금해하는 주제를 파악한 뒤 글을 작성합니다. AI가 글을 빠르게 생산해주기 때문에, 이 과정에서 시간을 아껴 주제 선정과 품질 검수에 더 집중할 수 있습니다.

원칙 3 : 검색엔진의 접근과 페이지 동작을 확인합니다

공개 글이 검색엔진에 차단되지 않는지, 실제 본문이 전달되는지, 주소와 링크가 정상인지부터 확인합니다. 구조화 데이터, 특정 개발 도구나 복잡한 사이트맵 구성이 모든 사이트의 필수 조건은 아닙니다.

원칙 4 : 필요한 글을 발행하고 기존 글도 고칩니다

발행 횟수 자체를 늘리는 것보다 실제 질문에 답하는 글과 오래된 정보의 수정이 우선입니다. AI로 초안을 빨리 만들었다면 남은 시간을 사실 확인과 설명 개선에 쓸 수 있습니다.

내 글 한 편에서 먼저 확인하기

사이트를 새로 만들거나 설정 파일부터 바꾸지 않고, 이미 공개한 글 하나를 고릅니다. 아직 사이트가 없다면 아래 내용 점검과 앞의 가상 수치 계산까지만 해도 됩니다.

1. 내용을 직접 확인합니다. 제목이 약속한 답이 본문에 있는지, 날짜와 숫자의 출처를 실제로 열어 확인할 수 있는지 봅니다. AI가 만들어 낸 경험은 지우고 직접 확인한 내용으로 바꿉니다.
2. 공개 페이지가 열리는지 봅니다. 로그아웃한 브라우저에서 해당 글을 엽니다. 로그인 화면이나 오류만 나온다면 검색 성과를 비교하기 전에 공개 범위를 확인합니다.
3. Search Console 권한이 있다면 URL 검사를 합니다. Search Console에서 관리할 사이트 속성을 선택하고 상단 URL 검사에 그 글의 전체 주소를 넣습니다. 색인 상태와 Google이 선택한 대표 URL을 봅니다. 권한이 없다면 관리자에게 결과 확인을 요청합니다.
4. 같은 조건의 실적을 기록합니다. 실적 보고서에서 페이지를 해당 주소로 좁히고, 완료된 28일과 앞선 28일의 노출 및 클릭을 비교합니다. 검색 유형, 국가와 기기 조건을 두 기간에 같게 둡니다.

등록되지 않았다면 아래처럼 다음 행동을 정합니다. 무조건 설정을 해제하거나 색인 요청을 반복하지 않습니다.

기본 URL 검사는 Google이 저장한 상태입니다. 방금 수정한 페이지가 현재 열리는지는 “실제 URL 테스트”로 따로 확인하며, 이 테스트가 성공해도 색인이나 상위 노출을 보장하지는 않습니다. URL 검사 설명

데이터가 없으면 먼저 사이트 속성과 주소, 날짜 필터가 맞는지 확인합니다. 새 글은 아직 데이터가 쌓이지 않았을 수 있으므로 곧바로 AI 사용에 따른 불이익이라고 판단하지 않습니다. 수정할 점을 한 가지 정해 반영하고, 다음에 같은 길이의 기간과 조건으로 다시 비교합니다. 그 전후 차이만으로도 원인이 확정되는 것은 아닙니다.

앞으로 남길 운영 기록

앞으로도 검색 변화와 운영 과정을 기록하려고 합니다. 전후 기록과 원인을 분리해 검증하는 실험은 구분하겠습니다.

앞으로 아래 내용을 주기적으로 공유할 예정입니다.

• Search Console 데이터 공개 : 실제 검색어, 노출 수, 클릭 수, 평균 순위 변화
• 콘텐츠 전략 공유 : 어떤 키워드를 타겟으로 글을 썼고, 결과가 어땠는지
• 기술적 SEO 변경 기록 : 사이트 구조, 렌더링 방식, 스키마 변경이 검색 성과에 미친 영향
• AI 활용 방식 공유 : AI로 글을 쓸 때의 프로세스와 품질 관리 방법

이 기록은 한 사이트의 사례이므로 모든 AI 콘텐츠의 성과를 대신 설명하지는 못합니다. AI 시대의 검색 환경 변화가 궁금하다면 AI Overviews 이후 오가닉 CTR 변화와 제로클릭 마케팅 전략도 함께 확인해 보세요. 당시에는 검색 관련 지표의 상승을 관찰했습니다.

이 두 번째 그림은 GA4의 세션 보고서입니다. google / organic은 구글 자연 검색으로 분류된 방문 활동이며 첫 번째 그래프의 검색 노출과 더해서 계산하지 않습니다.

3줄 요약

1. Google은 AI 사용 여부만으로 콘텐츠를 일괄 금지하지 않지만 검색 조작을 위한 대량의 저가치 콘텐츠는 스팸 정책에 위배될 수 있습니다.

2. 준이아빠블로그의 검색 노출 증가는 AI 활용과 사이트 개편 및 발행이 함께 진행된 운영 기록이며 특정 작업의 효과만 분리해 증명하지는 못합니다.

3. 처음에는 글 한 편의 정확성과 검색 등록 상태를 확인하고 같은 조건의 노출과 클릭을 기간별로 비교합니다.