AI로 만든 웹사이트의 SEO: 실제로 중요한 것

AI로 만든 웹사이트도 다른 웹사이트만큼 순위에 오를 수 있습니다. 검색 엔진은 페이지가 무엇을 담고 있고 방문자에게 얼마나 잘 맞는지를 평가하지, 어떤 도구로 코드를 썼는지를 평가하지 않습니다. 문제는 기술적인 부분입니다. 많은 AI 빌더는 브라우저에 거의 빈 HTML 파일을 보내고 JavaScript로 콘텐츠를 그리는 싱글 페이지 앱을 만들며, 이는 크롤러가 각 페이지를 읽고 공유하기 어렵게 만듭니다. 이를 해결하려면 프리렌더링이나 서버 렌더링을 사용하고, 모든 페이지에 고유한 제목, 설명, URL을 주고, 사이트맵을 추가하고, 속도를 유지하세요. 그리고 어떤 도구도 대신해 주지 못하는 부분, 즉 사람들이 검색하는 내용을 쓰는 일을 하세요.

싱글 페이지 앱이 검색에서 어려움을 겪는 이유

전통적인 웹사이트는 각 페이지의 전체 텍스트를 HTML에 담아 보냅니다. 싱글 페이지 앱(SPA)은 많은 AI 빌더의 기본 출력물로, 보통 Vite와 함께 쓰는 React입니다. 이는 빈 <div id="root"> 같은 작은 HTML 껍데기와 JavaScript 번들을 보냅니다. 브라우저가 JavaScript를 실행하면 그때 페이지가 만들어집니다.

이것이 검색에 영향을 주는 방식은 세 가지입니다.

1. 렌더링은 추가 단계입니다. Google은 JavaScript 페이지를 세 단계로 설명합니다. HTML을 크롤링하고, 헤드리스 Chromium 브라우저에서 렌더링하고, 렌더링된 결과를 색인합니다. Google의 가이드도 서버 사이드 렌더링이나 프리렌더링이 여전히 좋은 방법이라고 말합니다. 사용자와 크롤러 모두에게 더 빠르고, 모든 봇이 JavaScript를 실행할 수 있는 것은 아니기 때문입니다.
2. 페이지의 다른 독자는 렌더링하지 않습니다. 채팅 앱과 소셜 네트워크의 링크 미리보기, 그리고 그 밖의 많은 크롤러는 보통 처음 받은 HTML만 읽습니다. 제목과 미리보기 이미지가 로드 후 JavaScript로 설정된다면, 미리보기에는 빈 껍데기의 기본값이 나타나며 종종 모든 페이지가 같은 제목을 갖게 됩니다.
3. 모든 것이 하나의 HTML 파일을 공유합니다. 앱이 이를 갱신하지 않는 한, 모든 URL은 같은 <title>과 설명을 가지므로 검색 엔진은 각 페이지에 대해 거의 알 수 없습니다.

이것이 SPA를 색인할 수 없다는 뜻은 아닙니다. 크롤러가 더 많은 일을 해야 하고, 렌더링하지 않는 독자가 보는 내용을 통제할 수 없게 된다는 뜻입니다.

렌더링 방식 선택하기

크롤러에게 실제 HTML을 전달하는 흔한 방법은 네 가지입니다. 앱을 얼마나 많이 바꾸는지에 따라 대략 순서대로 나열했습니다.

실용적인 원칙은 이것입니다. 사이트에서 검색되어야 하는 공개 부분은 정적이거나 프리렌더링되어야 하고, 그 뒤의 로그인한 앱은 일반 SPA로 둘 수 있습니다. 어차피 검색 엔진이 대시보드를 색인할 이유는 없습니다.

처음부터 새로 만드는데 SEO가 중요하다면, AI가 적절한 구성을 고르도록 첫 프롬프트에서 그 점을 말하세요.

물리치료 클리닉을 위한 마케팅 사이트를 만들어 주세요. 홈, 서비스(서비스마다 한 페이지), 소개, 가격, 문의 페이지가 필요합니다. SEO가 중요하므로 각 페이지는 전체 콘텐츠와 고유한 제목, 메타 설명을 초기 HTML에 담아야 합니다. 클라이언트만으로 동작하는 싱글 페이지 앱이 아니라 정적 또는 프리렌더링 방식을 사용해 주세요.

이미 Vite SPA가 있다면, 공개 경로의 프리렌더링을 요청하세요.

이 React 앱은 그대로 두고, 공개 경로(/, /pricing, /about, /blog, 각 /blog/:slug)를 빌드 시점에 정적 HTML로 프리렌더링해 주세요. 각 페이지에는 고유한 제목, 메타 설명, 표준 URL, Open Graph 태그가 있어야 합니다. 로그인한 /app 경로는 클라이언트 렌더링으로 둬도 됩니다.

그 뒤에는 직접 확인하세요. 페이지를 열고 페이지 소스 보기를 선택하세요(개발자 도구의 Elements 패널은 렌더링된 페이지를 보여 주므로 쓰지 마세요). 텍스트와 제목이 원시 HTML에 들어 있는지 확인합니다.

기본 온페이지 요소 제대로 갖추기

아래 항목은 렌더링 방식과 상관없이 적용됩니다.

제목과 메타 설명

• 페이지마다 고유한 <title>을 하나 두고, 페이지의 핵심 주제를 앞에 두세요. 보통 약 50~60자가 권장되는데, 더 긴 제목은 검색 결과에서 잘리기 쉽기 때문입니다.
• 페이지마다 고유한 메타 설명을 하나 두세요. 키워드 목록이 아니라 사람들이 클릭하고 싶어 할 문장이어야 합니다. Google이 이를 다시 쓸 수도 있지만, 좋은 설명은 자주 그대로 쓰입니다.
• 메타 키워드는 쓰지 마세요. Google은 이 태그가 색인과 순위에 영향을 주지 않는다고 말합니다.

URL, 제목 태그, 링크

• 실제 페이지에는 실제 URL을. 모든 콘텐츠에는 자체 경로(/services/sports-massage)가 필요합니다. 클릭해야만 생기는 탭이나 모달에 두면 안 됩니다. 색인되기를 원하는 콘텐츠에는 # 프래그먼트 라우팅을 피하세요.
• 페이지당 h1 하나, 그다음 적절한 h2/h3 구조. AI가 만든 디자인은 스타일링을 위해 제목 태그를 쓰기도 하므로, 의미에 맞는 제목 태그를 요청하세요.
• 크롤링 가능한 링크. 탐색에는 실제 <a href> 링크를 쓰세요. JavaScript로 페이지를 바꾸는 버튼은 링크를 따라가는 크롤러에게 보이지 않습니다.
• 표준(canonical) 태그로 각 페이지가 선호하는 URL을 가리키게 하세요. 그래야 ?utm= 변형이나 끝에 슬래시가 있는 중복 주소가 서로 경쟁하지 않습니다.
• 의미 있는 이미지에는 설명이 담긴 대체 텍스트를 넣으세요.

소셜 미리보기

모든 공개 페이지에 Open Graph 태그(og:title, og:description, og:image, og:url)를 초기 HTML에 넣으세요. 링크 미리보기 봇은 JavaScript를 실행하지 않기 때문에, 이는 SPA가 가장 자주 놓치는 부분입니다.

사이트맵과 robots.txt

사이트맵은 색인되기를 원하는 URL을 나열한 XML 파일입니다. 특히 외부 링크가 적은 새 사이트에서 검색 엔진이 페이지를 찾는 데 도움이 됩니다. Google 문서에 따르면 2026년 9월 기준으로 다음과 같습니다.

• 사이트맵 하나에는 최대 50,000개의 URL 또는 압축하지 않은 상태로 50MB까지 담을 수 있습니다. 더 큰 사이트는 사이트맵 인덱스로 나누세요.
• Google은 <priority>와 <changefreq>를 무시합니다.
• Google은 <lastmod>가 일관되게 정확할 때만 사용하므로, 빌드할 때마다 바꾸지 말고 실제 콘텐츠가 바뀌었을 때만 갱신하세요.

robots.txt 파일은 크롤러에게 크롤링하지 말아야 할 경로를 알려 줍니다. /app, /admin, API 경로를 크롤러에서 제외하고, 여기에서 사이트맵 위치를 알려 주는 데 씁니다. robots.txt는 크롤링을 막을 뿐 색인을 막지는 않는다는 점을 기억하세요. 페이지를 검색 결과에서 빼려면 noindex 로봇 메타 태그를 쓰고, 그 페이지는 크롤링되도록 두어야 합니다.

사이트가 최종 도메인에 올라가면 Google Search Console에 사이트맵을 제출하세요. Search Console은 어떤 페이지가 색인되었고 다른 페이지는 왜 안 되었는지도 보여 줍니다. 가장 유용한 무료 SEO 도구입니다.

구조화 데이터

구조화 데이터는 페이지가 무엇인지 설명하는 기계 판독용 마크업입니다. 조직, 지역 업체, 제품, 기사, 이벤트 등을 설명합니다. Google은 JSON-LD 형식을 권장하며 두 가지를 분명히 합니다.

• 리치 결과에 노출될 자격을 얻게 할 수 있지만 보장하지는 않습니다.
• 페이지에 보이는 정보를 설명해야 합니다. 방문자가 볼 수 없는 리뷰, 가격, FAQ에 마크업을 달지 마세요.

시작점으로 적당한 것은 홈페이지의 Organization 또는 LocalBusiness, 제품 페이지의 Product, 블로그 글의 Article, 깊은 페이지의 BreadcrumbList입니다. Google의 리치 결과 테스트로 확인하세요.

JSON-LD 구조화 데이터를 추가해 주세요. 홈페이지에는 페이지에 이미 표시된 주소, 전화번호, 영업시간을 사용한 LocalBusiness를, 각 블로그 글에는 Article을 넣어 주세요. 평점이나 리뷰는 추가하지 마세요.

속도와 모바일

Google은 Core Web Vitals를 포함한 페이지 경험 신호를 사용하며, 속도는 방문자에게 어쨌든 중요합니다. 페이지 로드의 75번째 백분위수로 측정한 Google의 ‘좋음’ 기준은 다음과 같습니다.

AI로 만든 사이트에서 흔히 쓰는 해결책은 다음과 같습니다.

• 이미지 — 크기를 줄이고 압축하며, 최신 형식을 쓰고, 너비와 높이를 지정해 레이아웃 이동을 막고, 화면 아래쪽 이미지는 지연 로딩하세요.
• JavaScript — 번들이 크면 SPA의 모든 것이 느려집니다. 프리렌더링이 도움이 되고, 경로별로 코드를 나누는 것도 도움이 됩니다.
• 글꼴 — 글꼴 패밀리와 굵기를 줄이고, 첫 화면에 보이는 글꼴은 미리 로드하세요.
• 서드파티 스크립트 — 채팅 위젯과 추적 픽셀 하나하나가 속도를 떨어뜨립니다. 실제로 쓰는 것만 남기세요.

라이브 URL은 모바일 모드에서 PageSpeed Insights나 Lighthouse로 테스트하세요.

그래도 가장 중요한 것은 콘텐츠

기술적 SEO는 장애물을 없애 줄 뿐, 수요를 만들어 주지는 않습니다. 페이지는 다른 선택지보다 검색에 더 잘 답하기 때문에 순위에 오릅니다. 대부분의 작은 사이트에서 이는 다음을 뜻합니다.

• 사람들이 검색하는 주제마다 한 페이지. 배관공이라면 모든 서비스를 나열한 “서비스” 페이지 하나가 아니라, 서비스마다 그리고 서비스 지역마다 한 페이지가 필요합니다.
• 구체적이고 독창적인 세부 정보 — 가격, 과정, 실제 작업 사진, 고객이 전화로 자주 묻는 질문에 대한 답.
• 바뀌면 갱신하기. 오래된 영업시간과 낡은 가격은 신뢰를 빠르게 잃게 합니다.

AI는 페이지를 빠르게 초안으로 만들 수 있어서, 얇고 비슷한 페이지를 많이 발행하고 싶은 유혹이 생깁니다. 그러나 Google의 지침은 사람을 돕기보다 순위를 노리기 위해 주로 만든 콘텐츠를 겨냥하며, 어떻게 만들었는지는 상관없습니다. AI로 초안을 쓰고, 당신만 아는 내용을 더하세요. 디렉터리형 사이트가 이 문제를 가장 많이 겪습니다. 목록 페이지를 색인할 가치가 있게 만드는 방법은 디렉터리 웹사이트 만드는 법을 참고하세요.

출시 체크리스트

• 공개 페이지는 전체 콘텐츠를 초기 HTML에 담는다(페이지 소스 보기로 확인)
• 모든 페이지에 고유한 제목, 메타 설명, 표준 URL이 있다
• 모든 공개 페이지에 Open Graph 태그와 공유 이미지가 있다
• 페이지마다 h1은 하나, 실제 <a href> 링크를 쓰고, 이미지에는 대체 텍스트가 있다
• 실제 URL이 담긴 sitemap.xml이 있고, robots.txt가 앱과 API 경로를 막는다
• 구조화 데이터는 보이는 콘텐츠만 설명하며 테스트를 마쳤다
• 모바일에서 LCP, INP, CLS가 ‘좋음’ 범위에 있다
• 최종 도메인, HTTPS를 쓰며 Search Console에 제출했다

검색 트래픽을 키우기 전에 자체 도메인으로 옮겨 두면 나중에 리디렉션을 피할 수 있습니다. 커스텀 도메인 연결 방법을 참고하세요. 전체 제작 과정은 AI로 웹사이트 만드는 법을, 방문자를 전환시키는 페이지는 전환되는 랜딩 페이지 만드는 법을 읽어 보세요.

Mythex에서의 SEO

Mythex에는 별도의 SEO 패널이 없습니다. 채팅이나 코드로 앱을 변경하면서 SEO를 개선합니다. 새 웹 앱은 기본적으로 Vite와 React 싱글 페이지 앱으로 만들어지므로, 검색이 중요하다면 처음부터 정적 또는 프리렌더링 사이트나 Next.js를 요청하세요. 문서에는 제목, Open Graph 태그, 사이트맵, robots.txt를 위한 시작 프롬프트가 앱의 SEO에 있고, 콘텐츠 중심 사이트는 정적 웹사이트에서 다룹니다. 변경 후에는 다시 게시해야 라이브 사이트에 반영됩니다. 커스텀 도메인은 Pro에서 사용할 수 있습니다.

자주 묻는 질문