바이브코딩 SEO 기술 점검표: AI에게 꼭 확인시킬 12가지

AI에게 “SEO도 적용해줘”라고 부탁하면 제목과 설명을 몇 줄 추가한 뒤 완료했다고 말할 때가 있습니다.

하지만 검색엔진 최적화는 제목 하나로 끝나지 않아요. 구글이 페이지에 접근할 수 있는지, 검색에서 제외하는 설정이 잘못 들어가지 않았는지, 같은 페이지가 여러 주소로 보이지 않는지, 사이트맵과 실제 페이지가 일치하는지까지 함께 확인해야 합니다.

SEO와 검색 노출의 전체 과정을 아직 읽지 않았다면 먼저 배포·발견·수집·색인의 차이부터 살펴보세요. 이 글에서는 그다음 단계인 기술 SEO 점검에 집중합니다.

기술 SEO는 검색엔진이 길을 잃지 않게 하는 일이에요

콘텐츠가 좋아도 검색엔진이 페이지를 열지 못하거나 검색 제외 신호를 받으면 검색 결과에 나오기 어렵습니다.

기술 SEO는 다음 네 가지 질문을 확인하는 일이라고 생각하면 쉬워요.

검색엔진이 페이지에 들어올 수 있는가?
페이지의 내용을 읽고 이해할 수 있는가?
어떤 주소를 대표로 저장해야 하는지 알 수 있는가?
사용자가 불편하지 않게 페이지를 열 수 있는가?

설정 파일을 직접 읽을 필요는 없습니다. 대신 AI가 “문제없어요”라고만 답하지 못하게 하고, 어디를 확인했는지와 실제 증거를 함께 보고하게 하는 것이 중요합니다.

수정 전에 읽기 전용 점검부터 시키세요

SEO 설정은 여러 페이지에 영향을 줍니다. AI가 확인과 수정을 동시에 하면 무엇이 원래 문제였고 무엇을 바꿨는지 알기 어려워요.

먼저 다음 원칙으로 점검을 요청하세요.

아직 코드를 수정하지 마.
로컬 코드와 실제 배포 주소를 모두 확인해서
SEO 기술 점검 결과를 표로 정리해줘.

각 항목마다 다음 내용을 포함해줘.
- 현재 상태: 통과 / 주의 / 실패 / 확인 불가
- 확인한 파일이나 실제 URL
- 판단 근거
- 검색 노출에 미치는 영향
- 권장 수정 방법

추측하지 말고 확인하지 못한 것은 확인 불가로 표시해줘.

이 요청을 먼저 해두면 AI의 답을 작업 계획처럼 검토한 뒤 수정 범위를 선택할 수 있습니다.

1. 실제 배포 주소와 응답 상태

로컬에서 화면이 잘 열린다고 실제 배포 사이트도 같은 상태라는 보장은 없습니다. SEO 점검에는 localhost가 아니라 사용자가 들어오는 실제 배포 주소가 필요해요.

AI에게 주요 공개 페이지를 직접 열어 다음을 확인하게 하세요.

• 정상 페이지는 성공 상태로 응답하는가?
• 존재하지 않는 주소는 제대로 찾을 수 없음 상태를 반환하는가?
• 이전 주소가 새 주소로 이동한다면 리디렉션이 반복되지 않는가?
• http와 https, 여러 도메인이 한 대표 주소로 정리되는가?
• 로그인이나 오류 화면이 정상 페이지처럼 응답하지 않는가?

화면이 보이는지만 확인하면 부족합니다. 검색엔진은 서버가 돌려주는 상태 코드도 함께 읽기 때문에 AI가 각 URL의 응답 상태와 최종 도착 주소를 보고하게 해야 합니다.

배포 주소와 localhost가 왜 다른지 낯설다면 배포 글을 먼저 참고해도 좋아요.

2. robots.txt와 검색 접근 범위

robots.txt는 검색엔진 크롤러가 어느 주소에 접근할 수 있는지 알려주는 파일입니다.

전체 사이트를 실수로 막는 규칙이 들어가면 구글이 공개 페이지를 읽지 못할 수 있어요. 반대로 관리자나 내부 처리 주소를 사이트맵에 넣고 모든 크롤러에게 열어두는 것도 좋지 않습니다.

AI에게 다음을 확인시켜야 합니다.

• 운영 환경에서 전체 사이트를 막는 규칙이 없는가?
• 홈페이지, 소개, 상품, 블로그 같은 공개 페이지를 허용하는가?
• 관리자와 내부 처리 주소가 불필요하게 노출되지 않는가?
• robots.txt에 적힌 사이트맵 주소가 실제 운영 도메인과 일치하는가?
• 개발용 도메인이나 예전 주소가 남아 있지 않은가?

중요한 점이 하나 있어요. robots.txt는 보안 장치가 아닙니다. 주소를 숨기거나 로그인을 대신해주지 않아요. 개인정보가 있는 페이지는 로그인과 권한 검사로 보호해야 합니다.

3. noindex가 필요한 곳과 없어야 할 곳

noindex는 페이지를 검색 결과에 넣지 말라는 신호입니다.

로그인, 결제 완료, 관리자 화면처럼 검색할 필요가 없는 페이지에는 적절할 수 있어요. 하지만 홈페이지나 블로그에 실수로 들어가면 검색 노출을 직접 막습니다.

AI에게 코드의 메타데이터뿐 아니라 실제 배포 페이지가 보내는 HTML과 응답 헤더까지 확인하게 하세요.

• 주요 공개 페이지에 noindex가 없는가?
• 로그인 후 페이지와 개인정보 페이지는 검색에서 제외되는가?
• 페이지 설정과 서버 응답 헤더가 서로 충돌하지 않는가?
• 개발 환경용 설정이 운영 환경에도 적용되지 않았는가?

구글 공식 문서 (새 탭에서 열림)에 따르면 크롤러가 페이지에 접근해야 그 안의 noindex 신호도 읽을 수 있습니다. robots.txt로 접근을 막아놓고 페이지 안의 noindex만 추가하는 방식은 의도대로 작동하지 않을 수 있어요.

4. 페이지별 제목과 설명

모든 페이지가 같은 제목을 사용하면 사람과 검색엔진 모두 페이지를 구분하기 어렵습니다.

AI에게 주요 공개 페이지마다 다음 항목을 표로 뽑게 하세요.

URL | 페이지 제목 | 설명 | 중복 여부 | 개선 제안

점검 기준은 단순합니다.

• 제목이 페이지의 실제 내용을 구체적으로 설명하는가?
• 서비스 이름만 반복하지 않고 페이지마다 차이가 있는가?
• 설명이 검색어 목록이 아니라 방문자가 얻을 내용을 말하는가?
• 빈 값이나 Next.js App 같은 기본 문구가 남아 있지 않은가?
• 화면의 제목과 검색용 제목이 서로 전혀 다른 내용을 말하지 않는가?

검색 결과의 설명은 구글이 본문을 바탕으로 다르게 만들 수 있습니다. 메타 설명을 입력했다고 그 문장이 항상 그대로 표시되는 것은 아니므로, 본문 자체도 페이지 주제를 분명하게 설명해야 해요.

5. 대표 URL을 정하는 canonical

같은 내용이 여러 주소에서 열릴 수 있습니다.

https://example.com/program
https://www.example.com/program
https://example.com/program?ref=instagram

검색엔진은 이 중 어떤 주소를 대표로 저장할지 판단해야 합니다. 대표 주소를 알려주는 신호가 canonical이에요.

AI에게 다음을 확인시켜야 합니다.

• 각 공개 페이지의 canonical이 실제 운영 주소를 가리키는가?
• 모든 페이지가 홈페이지 하나를 canonical로 가리키는 실수가 없는가?
• www 유무와 http, https가 일관적인가?
• 추적용 주소나 필터 주소가 별도 페이지처럼 중복되지 않는가?
• 사이트맵의 주소와 canonical 주소가 서로 일치하는가?

canonical은 단순히 태그 하나를 넣는 작업이 아니라 리디렉션, 내부 링크, 사이트맵이 같은 대표 주소를 가리키도록 맞추는 작업입니다.

6. sitemap.xml의 실제 내용

사이트맵 파일이 존재하는지만 확인하면 부족합니다. 안에 들어 있는 주소가 정확해야 해요.

좋은 사이트맵에는 보통 다음 조건을 만족하는 페이지가 들어갑니다.

• 로그인 없이 열리는 공개 페이지
• 정상적으로 응답하는 페이지
• 검색에 포함하려는 대표 URL
• 실제 운영 도메인을 사용하는 URL

반대로 관리자, 로그인, 결제 결과, 오류 페이지와 검색 제외 페이지는 보통 넣지 않습니다.

블로그나 상품처럼 페이지가 계속 늘어난다면 새 콘텐츠가 사이트맵에 자동으로 포함되는지도 확인해야 해요. 날짜를 제공한다면 실제로 내용이 바뀐 시점을 반영해야 하며, 매번 현재 시각을 넣어 모든 페이지가 새로 바뀐 것처럼 만들 필요는 없습니다.

사이트맵에 넣을 URL, 제외할 URL과 정확한 수정 날짜를 정하는 방법은 sitemap.xml을 설명한 글에서 이어서 살펴보세요.

7. 검색엔진이 따라갈 수 있는 내부 링크

페이지를 만들었어도 다른 곳에서 연결되지 않으면 검색엔진과 사용자 모두 발견하기 어렵습니다. 이런 페이지를 고립된 페이지라고 해요.

구글은 일반적으로 실제 주소가 들어 있는 링크를 따라 페이지를 발견합니다. 버튼을 눌렀을 때 JavaScript만 실행해 이동하는 구조는 검색엔진이 링크로 해석하지 못할 수 있어요. 구글의 링크 권장사항 (새 탭에서 열림)도 주소가 있는 링크 요소 사용을 안내합니다.

AI에게 다음을 점검하게 하세요.

• 주요 공개 페이지가 메뉴나 본문 링크로 연결돼 있는가?
• 클릭 가능한 요소가 실제 목적지 주소를 가지고 있는가?
• “여기 클릭”보다 연결될 페이지를 설명하는 문구를 사용하는가?
• 깨진 링크와 존재하지 않는 주소가 없는가?
• 사이트맵에는 있지만 사이트 어디에서도 연결되지 않은 페이지가 없는가?

블로그 글 사이의 관련 글 링크도 독자의 다음 행동을 돕는 동시에 각 페이지의 관계를 검색엔진에 알려줍니다.

모든 내용을 한 URL에 담을지 주제별 페이지로 나눌지 고민된다면 한 페이지짜리 웹사이트도 SEO가 되는지 설명한 글을 함께 살펴보세요.

8. 제목 구조와 이미지 설명

화면에서 글자가 크게 보인다고 검색엔진도 자동으로 제목이라고 이해하는 것은 아닙니다. 페이지의 대표 제목과 소제목이 논리적인 순서를 가져야 해요.

AI에게 다음을 확인시킬 수 있습니다.

• 페이지의 대표 제목이 분명한가?
• 소제목이 내용의 순서에 맞게 구성됐는가?
• 중요한 본문이 이미지 안에만 들어 있지 않은가?
• 내용이 있는 이미지에는 적절한 대체 텍스트가 있는가?
• 장식용 이미지를 억지로 긴 문장으로 설명하지 않는가?

대체 텍스트는 검색엔진뿐 아니라 화면 읽기 도구를 사용하는 사람에게도 이미지를 설명합니다. 파일명을 반복하거나 검색어를 나열하기보다 이미지가 전달하는 정보를 짧고 구체적으로 적는 것이 좋아요.

9. JSON-LD 구조화 데이터는 실제 내용과 일치해야 해요

구조화 데이터는 검색엔진에 글, 상품, 행사 같은 정보의 종류를 정해진 형식으로 알려주는 데이터입니다. 웹 프로젝트에서는 보통 HTML 안에 <script type="application/ld+json"> 형태로 넣는 JSON-LD 방식을 사용해요. 방문자 화면에 새로운 문장을 보여주는 코드는 아니지만, 검색엔진이 페이지의 의미를 이해하는 데 도움을 줍니다.

예를 들어 블로그 글에는 Article이나 BlogPosting, 상품 페이지에는 Product처럼 실제 페이지 성격에 맞는 유형을 선택합니다. AI가 모든 페이지에 같은 유형을 복사하거나, 화면에 없는 저자·평점·가격을 임의로 만들어 넣지 않았는지 확인해야 해요.

잘 적용하면 검색 결과가 더 풍부하게 보일 가능성이 있지만, 넣었다고 무조건 특별한 검색 결과가 보장되는 것은 아닙니다. 페이지에 실제로 보이지 않는 후기나 가격을 구조화 데이터에만 적어서는 안 돼요.

구조화 데이터, Schema.org와 리치 결과를 먼저 이해하고 싶다면 JSON-LD의 역할과 적용 방법을 살펴보세요. 이 글에서는 개념 설명보다 실제 점검 항목에 집중합니다.

AI에게 다음 원칙으로 확인시키세요.

• JSON-LD가 실제 렌더링된 HTML에 포함되는가?
• 현재 페이지에 맞는 유형(Article, BlogPosting, Product 등)을 사용하는가?
• 화면에 보이는 제목, 날짜, 가격과 데이터가 일치하는가?
• 필수 항목이 빠지거나 형식이 잘못되지 않았는가?
• Google 리치 결과 테스트 (새 탭에서 열림)에서 오류가 없는가?
• 모든 페이지에 같은 데이터를 복사해 넣지 않았는가?

구조화 데이터는 기본 검색 노출을 만드는 첫 단계가 아니라, 접근·색인·콘텐츠가 정상인 다음에 검토할 항목입니다.

10. 모바일 화면과 Core Web Vitals

검색 방문자의 상당수는 모바일로 들어옵니다. 글자가 너무 작거나 버튼이 겹치고, 화면이 늦게 뜨거나 로딩 중 크게 흔들리면 사용하기 어렵습니다.

Core Web Vitals는 실제 사용 경험을 세 가지로 나눠 측정합니다.

LCP  주요 내용이 보이기까지 걸리는 시간
INP  클릭과 입력에 반응하는 속도
CLS  로딩 중 화면이 흔들리는 정도

구글이 권장하는 좋은 기준은 LCP 2.5초 이내, INP 200밀리초 미만, CLS 0.1 이하입니다. 다만 점수 하나만 맞추기보다 실제 모바일 화면이 읽고 누르기 편한지 함께 확인해야 해요.

AI에게 모바일 화면 캡처, 큰 이미지, 불필요한 스크립트, 레이아웃 흔들림의 원인을 찾게 하고 수정 전후 측정 결과를 비교하게 하세요.

11. Open Graph는 검색 노출과 역할이 달라요

카카오톡이나 슬랙에 링크를 붙였을 때 나오는 카드에는 Open Graph 정보가 사용됩니다.

검색용 제목과 설명   검색 결과를 이해하는 데 도움
Open Graph          메신저와 SNS 링크 미리보기

둘 다 제목과 설명을 사용해서 헷갈리지만 목적이 달라요. OG 이미지가 잘 나온다고 구글 색인이 완료된 것은 아니고, 구글 검색에 나온다고 카카오톡 대표 이미지가 자동으로 완성되는 것도 아닙니다.

AI에게 홈페이지뿐 아니라 블로그와 상품처럼 공유할 가능성이 높은 페이지에도 올바른 제목, 설명, 절대 주소의 대표 이미지가 생성되는지 확인하게 하세요.

12. 프로덕션 빌드와 배포 후 재확인

코드만 보고 문제가 없다고 판단하면 실제 환경의 차이를 놓칠 수 있습니다.

수정이 끝나면 AI에게 다음 순서로 검증하게 하세요.

1. 타입 검사와 프로덕션 빌드를 통과합니다.
2. 사이트를 다시 배포합니다.
3. 실제 운영 주소에서 주요 페이지를 엽니다.
4. 제목, canonical, robots와 응답 상태를 다시 확인합니다.
5. sitemap.xml의 모든 주소가 정상적으로 열리는지 검사합니다.
6. 모바일 화면과 기본 성능을 측정합니다.

Next.js가 프론트엔드와 서버를 어떻게 함께 다루는지 이해하면 AI가 왜 코드와 실제 배포 환경을 모두 점검해야 하는지도 파악하기 쉬워요.

AI에게 한 번에 요청하는 기술 SEO 점검 프롬프트

아래 요청문에 실제 배포 주소를 넣어 사용할 수 있습니다.

이 프로젝트의 기술 SEO를 읽기 전용으로 감사해줘.
아직 코드는 수정하지 마.

실제 배포 주소: [https://내도메인.com]

다음 항목을 로컬 코드와 실제 배포 환경에서 각각 확인해줘.
1. 주요 URL의 응답 상태와 리디렉션
2. robots.txt의 허용·차단 범위와 사이트맵 주소
3. 공개 페이지의 noindex 및 X-Robots-Tag 여부
4. 페이지별 title과 description의 누락·중복
5. canonical과 실제 운영 도메인의 일치
6. sitemap.xml의 공개 URL 누락·오류·중복
7. 주요 페이지의 내부 링크와 깨진 링크
8. 대표 제목 구조와 이미지 alt 텍스트
9. JSON-LD 구조화 데이터의 유형·유효성과 화면 내용 일치 여부
10. 모바일 화면과 Core Web Vitals 위험 요소
11. Open Graph 제목·설명·이미지·절대 URL
12. 프로덕션 빌드 결과

결과는 아래 열을 가진 표로 작성해줘.
항목 | 상태 | 확인한 증거 | 영향 | 권장 수정

상태는 통과 / 주의 / 실패 / 확인 불가 중 하나로 표시해.
검색에서 제외해야 할 관리자·로그인·결제 결과 페이지와
검색에 포함해야 할 공개 페이지를 구분해서 평가해.
추측으로 통과 처리하지 마.

보고서를 검토한 뒤 수정할 때는 이렇게 범위를 정할 수 있어요.

감사 결과에서 실패와 주의 항목만 수정해줘.
먼저 검색 노출을 막는 문제를 해결하고,
그다음 중복 URL과 메타데이터, 내부 링크를 정리해줘.

관리자와 개인정보 페이지의 접근 권한은 바꾸지 마.
수정 뒤 프로덕션 빌드와 실제 배포 주소를 다시 확인하고,
바뀐 파일과 검증 결과를 항목별로 보고해줘.

AI가 확인할 수 없는 일도 있어요

AI가 코드와 공개 URL을 점검해도 Google Search Console 계정 안의 모든 상태를 자동으로 볼 수 있는 것은 아닙니다. 연결된 브라우저나 권한이 없다면 다음 작업은 사용자가 직접 해야 해요.

• Search Console 소유권 인증
• 사이트맵 제출 상태 확인
• URL 검사에서 실제 색인 상태 확인
• 검색어별 노출과 클릭 변화 확인
• Core Web Vitals의 실제 사용자 데이터 확인

AI에게 화면을 보여주거나 내보낸 데이터를 전달하면 해석은 도와줄 수 있지만, 접근 권한이 없는 상태에서 “Search Console도 정상”이라고 추측하게 해서는 안 됩니다.

Search Console과 네이버 서치어드바이저의 소유확인, 사이트맵 제출과 색인 상태 확인은 만든 홈페이지를 구글·네이버 검색에 등록하는 방법에서 단계별로 따라 할 수 있어요. 코드의 SEO 기본 설정부터 진행하려면 바이브코딩 가이드 14장의 SEO와 링크 미리보기 실습을 참고하세요.

정리

기술 SEO는 검색 순위를 보장하는 비법이 아닙니다. 좋은 콘텐츠가 검색엔진에 발견되고 올바른 주소로 저장될 수 있도록 방해 요소를 없애는 작업이에요.

• 실제 배포 주소와 응답 상태를 확인합니다.
• robots.txt와 noindex의 역할을 구분합니다.
• 페이지마다 고유한 제목과 설명을 제공합니다.
• canonical, 사이트맵과 내부 링크가 같은 대표 주소를 가리키게 합니다.
• 제목 구조, 이미지 설명과 JSON-LD 구조화 데이터를 실제 내용에 맞춥니다.
• 모바일 사용성과 Core Web Vitals를 확인합니다.
• Open Graph와 검색용 메타데이터의 목적을 구분합니다.
• 코드 수정 뒤 빌드와 실제 배포 환경을 다시 검사합니다.
• Search Console처럼 AI가 접근할 수 없는 영역은 직접 확인합니다.

바이브코딩에서 중요한 것은 이 설정을 직접 작성하는 능력이 아니에요. AI에게 확인 범위를 명확하게 주고, 통과했다는 말 대신 증거를 요구하고, 실제 배포 환경에서 다시 검증하게 하는 것입니다.