구글 서치 콘솔 사용법 7단계: 속성 등록부터 색인 요청, 실적 분석, 데이터 내보내기까지
구글 서치 콘솔(Google Search Console)은 내 사이트가 구글 검색에서 어떻게 발견되고, 색인되고, 노출되는지 보여 주는 Google의 무료 도구입니다. 사용법의 기본 흐름은 속성 추가와 소유권 확인 → Sitemaps 제출 → URL 검사로 색인 생성 요청 → 페이지 색인 생성 보고서 점검 → 실적 보고서로 검색어 분석 → Core Web Vitals 확인 → 데이터 내보내기, 이렇게 7단계입니다. 아래에서는 각 단계의 메뉴 이름과 버튼을 Search Console 고객센터의 공식 도움말 표기에 맞춰 정리했습니다.
시작하려면 구글 계정, 도메인 DNS를 수정할 수 있는 권한, 웹사이트 관리자 계정이 필요합니다. 사이트 구조와 메타 태그처럼 서치 콘솔 바깥에서 손봐야 할 기본기는 홈페이지 SEO 최적화 방법에서 따로 다루니, 이 글은 서치 콘솔 화면 안에서 무엇을 누르고 무엇을 읽어야 하는지에 집중합니다.
구글 서치 콘솔이란? GA4와 무엇이 다른가
서치 콘솔은 사이트 운영자가 Google 검색에서의 실적과 기술적 문제를 확인하는 공식 도구입니다. 사용자가 검색 결과에서 내 링크를 보고 클릭하기 전까지의 데이터, 즉 노출수, 클릭수, 평균 CTR, 평균 게재순위와 크롤링·색인 상태를 보여 줍니다.

구글 애널리틱스 4(GA4)는 방문자가 사이트에 들어온 후의 행동(페이지 조회, 이벤트, 전환)을 측정합니다. 두 도구는 측정 시점과 방식이 다르기 때문에 숫자가 정확히 일치하지 않는 것이 정상이며, 검색 유입 문제를 진단할 때는 둘을 나란히 보는 편이 좋습니다.
처음 열었을 때 자주 쓰게 될 보고서는 다음과 같습니다.
| 보고서/도구 | 메뉴 위치 | 확인할 수 있는 것 |
|---|---|---|
| 실적 보고서(Google 검색 결과) | 실적 | 검색어·페이지별 클릭수, 노출수, CTR, 게재순위 |
| URL 검사 | 화면 상단 검사 검색창 | 특정 URL의 색인 여부, 실제 URL 테스트, 색인 생성 요청 |
| 페이지 색인 생성 보고서 | 색인 생성 > 페이지 | 색인 생성된 페이지 수와 색인이 생성되지 않은 이유 |
| 사이트맵 보고서 | 색인 생성 > Sitemaps | 사이트맵 제출과 처리 상태 |
| Core Web Vitals 보고서 | 왼쪽 메뉴 Core Web Vitals | 실제 사용자 데이터 기준 LCP, INP, CLS 상태 |
| 설정 | 설정 | 사용자 및 권한, 소유권 확인, 대량 데이터 내보내기 |
시작 전 준비 사항
작업 도중 흐름이 끊기지 않도록 아래 항목을 먼저 준비해 두세요.

| 준비 항목 | 확인 위치 | 없으면 생기는 문제 |
|---|---|---|
| 구글 계정 | Google 계정 | 서치 콘솔에 로그인하거나 속성을 소유할 수 없음 |
| 도메인 DNS 관리 권한 | 가비아, 카페24, 후이즈, Cloudflare 등 도메인·DNS 관리 화면 | 도메인 속성의 DNS 레코드 확인 불가 |
| 웹사이트 관리자 권한 | 워드프레스 등 CMS 관리자 화면 또는 서버 | HTML 태그·HTML 파일 확인, robots.txt 수정 불가 |
| 사이트맵 주소 | CMS나 SEO 플러그인이 만든 sitemap.xml 주소 | Sitemaps 보고서에 제출할 주소가 없음 |
| robots.txt | 브라우저에서 https://도메인/robots.txt 열기 | 크롤링 차단 규칙을 모른 채 진행하게 됨 |
속성 유형은 처음에 정해 두는 것이 좋습니다. 아래 기준으로 도메인 속성과 URL 접두사 속성 중 하나를 고르세요.
1단계: 속성 추가하고 소유권 확인하기
이 단계의 목표는 사이트를 서치 콘솔에 등록하고, 내가 그 사이트의 소유자임을 증명하는 것입니다.

- 서치 콘솔 왼쪽 위의 속성 선택기 드롭다운을 열고 + 속성 추가를 선택합니다.
- 웹사이트 속성을 고른 뒤 도메인 속성과 URL 접두사 속성 중 하나를 선택합니다.
- 도메인 속성은 https://나 경로 없이 루트 도메인(예: example.com)만 입력합니다. 모든 하위 도메인(www, m 등)과 http/https가 하나의 속성으로 묶입니다.
- URL 접두사 속성은 https://www.example.com/처럼 프로토콜까지 포함한 주소를 입력합니다. 특정 경로(예: /ko/)나 프로토콜만 따로 보고 싶을 때 씁니다.
도메인 속성은 DNS 레코드로 소유권을 확인합니다. 화면에 표시되는 google-site-verification=으로 시작하는 TXT 값을 복사한 뒤, 도메인 등록 업체나 Cloudflare의 DNS 관리 화면에서 새 레코드를 추가합니다. 유형은 TXT, 이름(호스트)은 업체 안내에 따라 @ 또는 비워 두고, 값에는 복사한 문자열을 붙여 넣어 저장합니다. 다시 서치 콘솔로 돌아와 확인을 누릅니다.
URL 접두사 속성은 HTML 파일 업로드, HTML 태그, Google 애널리틱스, Google 태그 관리자 등 여러 확인 방법 중 사이트에 맞는 것을 고를 수 있습니다. 확인 방법은 나중에 속성의 설정 > 소유권 확인에서 하나 더 추가해 둘 수 있으며, 기존 방법이 실패할 때를 대비해 두 가지 이상 등록해 두는 것이 좋습니다.
가장 흔한 실패는 DNS 변경이 아직 반영되지 않은 상태에서 확인을 누르는 경우입니다. DNS 변경이 퍼지는 데는 시간이 걸릴 수 있으므로, TXT 값에 오타가 없는지 확인한 뒤 잠시 기다렸다가 다시 시도하세요. 이전에 등록한 TXT 레코드를 호스팅 이전 과정에서 지우면 소유권이 해제될 수 있으니 레코드는 남겨 둡니다.
예시: app.example.com과 blog.example.com을 URL 접두사 속성으로 따로 등록해 데이터가 흩어져 있던 사이트라면, 도메인 속성 example.com을 하나 추가하면 두 하위 도메인의 검색 실적을 한 화면에서 함께 볼 수 있습니다.
2단계: Sitemaps 보고서에서 사이트맵 제출하기
이 단계의 목표는 Google에 사이트맵 파일의 위치를 알려 주는 것입니다. 공식 도움말 표현대로, 사이트맵 '제출'은 파일을 업로드하는 것이 아니라 파일이 어디 있는지 알려 주는 일입니다.
- 제출 전에 브라우저 주소창에 사이트맵 주소를 직접 넣어 XML이 오류 없이 열리는지 확인합니다. URL 검사의 실제 URL 테스트로 사이트맵 주소를 검사해도 됩니다.
- 왼쪽 메뉴 색인 생성 > Sitemaps를 엽니다.
- 새 사이트맵 추가 상자에 사이트맵 주소의 뒷부분(예: sitemap.xml)을 입력하고 제출을 누릅니다.
- 아래 제출된 사이트맵 목록에서 상태와 발견된 페이지 수를 확인합니다.
상태는 성공, 가져올 수 없음, 사이트맵에 X개의 오류가 있음 중 하나로 표시됩니다. 성공이 아니면 해당 행을 클릭해 실패 이유를 확인하세요. 사이트맵 보고서로 제출하려면 속성의 소유자 권한이 필요하며, 소유자가 아니라면 robots.txt 파일에 Sitemap: 줄로 위치를 적어 두는 방법도 있습니다. RSS·Atom 피드도 사이트맵 형식으로 인정되므로, 새 글이 자주 올라오는 블로그라면 피드 주소를 함께 제출할 수 있습니다.
제출 전에 아래 10가지를 점검해 두면 '가져올 수 없음'이나 오류 상태를 상당 부분 미리 막을 수 있습니다.
| 번호 | 점검 항목 | 확인 방법 | 조치 |
|---|---|---|---|
| 1 | 사이트맵 접근성 | 브라우저에서 열었을 때 HTTP 200 응답 | 404이면 CMS·플러그인의 사이트맵 설정 확인 |
| 2 | robots.txt 허용 | 사이트맵 경로가 Disallow에 걸리지 않는지 확인 | 차단 규칙 제거, Sitemap: 줄 추가 |
| 3 | 로그인 차단 없음 | 시크릿 창에서 사이트맵이 열리는지 확인 | 로그인·방화벽 차단 해제 |
| 4 | noindex 페이지 제외 | 색인을 원하지 않는 URL이 사이트맵에 있는지 확인 | 장바구니, 관리자, 임시 페이지 제외 |
| 5 | 표준 URL만 포함 | 사이트맵 URL이 자기 자신을 canonical로 지정하는지 확인 | 매개변수 URL, 중복 URL 제거 |
| 6 | 리디렉션 URL 제외 | 사이트맵 URL이 3xx로 다른 주소로 넘어가지 않는지 확인 | 최종 도착 URL로 교체 |
| 7 | 프로토콜 통일 | 모든 URL이 https://로 시작하는지 확인 | http:// 주소 교체 |
| 8 | 크기 제한 | 파일 하나당 URL 50,000개, 압축 해제 기준 50MB 이하 | 초과 시 사이트맵 색인 파일로 분할 |
| 9 | lastmod 정확성 | 내용이 실제로 바뀐 날에만 날짜가 갱신되는지 확인 | 매일 자동으로 바뀌는 날짜 설정 해제 |
| 10 | 오류 페이지 제외 | 404·5xx를 반환하는 URL이 없는지 확인 | 삭제된 URL 제거 |
3단계: URL 검사로 색인 생성 요청하기
이 단계의 목표는 새로 발행했거나 크게 수정한 중요한 페이지를 Google에 다시 크롤링해 달라고 요청하는 것입니다.

- 서치 콘솔 화면 상단의 검사 검색창에 확인할 페이지의 전체 URL(예: https://example.com/new-post)을 입력합니다. URL은 현재 열려 있는 속성에 포함된 주소여야 합니다.
- 결과 상단에서 URL이 Google에 등록되어 있음 또는 URL이 Google에 등록되어 있지 않음 상태를 확인합니다. 이 결과는 실시간이 아니라 가장 최근에 색인된 버전을 기준으로 합니다.
- 페이지를 수정한 뒤라면 실제 URL 테스트를 눌러 현재 버전이 색인 가능한지 확인합니다.
- 문제가 없으면 색인 생성 요청을 누릅니다. 간단한 검사를 통과한 URL은 색인 생성 대기열에 제출됩니다.
주의할 점이 두 가지 있습니다. 첫째, 'URL이 Google에 등록되어 있음'이 곧 검색 결과 노출을 보장하지는 않습니다. 둘째, 하루에 요청할 수 있는 횟수는 속성별로 제한되어 있습니다. 새 글이나 수정한 글이 많다면 하나씩 요청하기보다 수정된 페이지에 <lastmod>를 표시한 사이트맵을 다시 제출하는 것이 공식 도움말이 권하는 방법입니다.
서치 콘솔에서 찾은 개선 후보 검색어를 실제 글 작업으로 옮기고 싶다면 Orova SEO를 써 보세요. 내 사이트 Search Console의 게재순위 8~30위 검색어를 우선 후보로 보고, 기존 글은 URL을 그대로 둔 채 고쳐 워드프레스에 다시 발행할 수 있습니다.
4단계: 페이지 색인 생성 보고서에서 색인되지 않은 이유 확인하기
이 단계의 목표는 중요한 페이지가 색인되지 않은 이유를 찾아 고칠 것과 그대로 둘 것을 가려내는 것입니다.

- 왼쪽 메뉴 색인 생성 > 페이지를 엽니다.
- 차트에서 색인 생성됨(녹색)과 색인이 생성되지 않음(회색) 페이지 수의 추이를 봅니다.
- 아래 페이지 색인이 생성되지 않는 이유 표에서 이유별 URL 수와 출처(웹사이트 또는 Google)를 확인합니다. 일반적으로 출처가 '웹사이트'인 문제만 직접 고칠 수 있습니다.
- 행을 클릭하면 해당 이유에 걸린 URL 예시 목록이 나옵니다. URL 옆의 검사 아이콘으로 개별 URL을 URL 검사 도구에서 열 수 있습니다.
- 모든 사례를 고친 뒤 문제 세부정보 페이지에서 수정 결과 확인을 누릅니다. 확인에는 보통 최대 2주 정도 걸리며, 그 사이에 버튼을 다시 누르지 않습니다.
먼저 알아 둘 점이 있습니다. 공식 도움말은 페이지가 500개 미만인 작은 사이트라면 이 보고서 대신 site: 검색과 URL 검사로 주요 페이지만 확인해도 충분할 수 있다고 안내합니다. 또 사이트의 모든 URL이 색인되는 것은 정상 목표가 아닙니다. 중복 페이지, 의도적으로 막은 페이지는 색인되지 않는 것이 맞습니다.
보고서에 자주 보이는 이유를 공식 표기 그대로 정리했습니다.
| 이유(보고서 표기) | 의미 | 확인 방법 | 조치 |
|---|---|---|---|
| 서버 오류(5xx) | Googlebot이 접속했을 때 서버가 5xx 오류를 반환함 | 실제 URL 테스트로 현재 응답 확인 | 서버 부하·플러그인 충돌 점검 후 수정 결과 확인 |
| 리디렉션 오류 | 리디렉션 체인이 너무 길거나 순환하거나, 빈 URL이 섞임 | 브라우저 개발자 도구로 리디렉션 경로 추적 | 한 번에 최종 URL로 이동하도록 정리 |
| URL이 robots.txt에 의해 차단됨 | robots.txt 규칙 때문에 크롤링하지 못함 | robots.txt에서 해당 경로 규칙 확인 | 의도한 차단이면 그대로, 아니면 규칙 수정 |
| URL이 'NOINDEX'로 표시됨 | 페이지 소스나 응답 헤더에 noindex가 있음 | 페이지 소스·응답 헤더에서 noindex 검색 | 색인이 필요한 페이지면 noindex 삭제 |
| Soft 404 | '찾을 수 없음' 같은 내용인데 404 코드를 반환하지 않음 | 실제 URL 테스트 후 테스트된 페이지 보기 | 없는 페이지는 404/410 반환, 있는 페이지는 내용 보강 |
| 찾을 수 없음(404) | 요청한 URL이 404를 반환함 | 링크·사이트맵에 남아 있는지 확인 | 이동한 페이지면 301 리디렉션, 삭제가 의도라면 그대로 |
| 크롤링됨 - 현재 색인이 생성되지 않음 | Google이 크롤링했지만 아직 색인하지 않음 | URL 검사로 마지막 크롤링 날짜 확인 | 내용이 얇거나 중복이 아닌지 점검하고 보강 |
| 발견됨 - 현재 색인이 생성되지 않음 | URL을 알고 있지만 아직 크롤링하지 않음 | URL 검사에서 크롤링 정보 확인 | 내부 링크로 중요 페이지 연결, 서버 응답 점검 |
| 사용자가 선택한 표준이 없는 중복 페이지 | 다른 페이지의 중복으로 판단됐고 canonical 지정이 없음 | URL 검사에서 Google에서 선택한 표준 확인 | 원본을 가리키는 canonical 지정 |
| 중복 페이지, Google에서 사용자와 다른 표준 URL을 선택함 | 지정한 canonical 대신 다른 URL을 표준으로 선택함 | 사용자 선언 표준과 Google 선택 표준 비교 | 내부 링크·사이트맵을 원하는 표준 URL로 통일 |
| 적절한 표준 태그가 포함된 대체 페이지 | 다른 페이지를 표준으로 가리키는 대체 페이지 | 표준 URL이 색인됐는지 확인 | 대부분 조치 불필요 |
| 리디렉션이 포함된 페이지 | URL이 다른 URL로 리디렉션됨 | 리디렉션 대상이 색인됐는지 확인 | 대부분 조치 불필요, 사이트맵에서는 최종 URL만 유지 |

'발견됨 - 현재 색인이 생성되지 않음' 상태에서 색인 생성 요청을 여러 번 눌러도 상태가 그대로인 경우가 많습니다. 요청 횟수보다 그 페이지로 들어오는 내부 링크와 서버 응답 상태, 페이지 내용 자체를 먼저 점검하는 편이 낫습니다.
예시: 색상·사이즈 필터마다 별도 URL이 생기는 쇼핑몰이라면 이 보고서에 중복 관련 이유가 대량으로 표시될 수 있습니다. 필터 URL이 대표 상품 페이지를 canonical로 가리키도록 정리하고 사이트맵에는 대표 페이지만 남기면, 색인되지 않은 URL 수가 많더라도 그것이 의도한 결과인지 쉽게 판단할 수 있습니다.
5단계: 실적 보고서에서 개선할 검색어 찾기
이 단계의 목표는 이미 노출은 되고 있지만 클릭이 적은 검색어를 찾아, 새 글을 쓰는 대신 기존 글을 고칠 후보로 삼는 것입니다.

- 왼쪽 메뉴 실적에서 Google 검색 결과 보고서를 엽니다. 기본 기간은 지난 3개월입니다.
- 상단의 총 클릭수, 총 노출수, 평균 CTR, 평균 게재순위 카드를 모두 눌러 네 가지 지표를 차트와 표에 함께 표시합니다.
- 표의 검색어 탭에서 노출수 열 제목을 눌러 노출이 많은 순으로 정렬합니다.
- 평균 게재순위가 1페이지 바로 아래에 걸쳐 있으면서 노출이 많은 검색어를 고릅니다. 기준 순위 구간(예: 8~30위)은 사이트 상황에 맞게 직접 정하세요. 화면에서 바로 거르기 어렵다면 내보내기로 표를 내려받아 스프레드시트에서 게재순위 열로 거르면 됩니다.
- 특정 검색어 행을 클릭하면 그 검색어로 필터가 걸립니다. 이 상태에서 페이지 탭을 열면 그 검색어로 노출되는 URL을 확인할 수 있습니다.
국가·기기·페이지 같은 조건은 보고서 상단의 + 필터 추가로 걸 수 있습니다. 검색어나 URL로 필터를 걸면 익명 처리된 검색어가 빠지면서 총계가 달라질 수 있다는 점도 공식 도움말에 안내되어 있습니다.
5번에서 한 검색어에 내 글 두세 개가 번갈아 노출된다면 키워드 카니발리제이션(서로 순위를 나눠 먹는 현상)을 의심해 볼 수 있습니다. 이 경우 한 글로 내용을 합치고 나머지 URL은 301 리디렉션하거나, 글마다 다루는 검색 의도를 분명히 나누는 방법을 검토합니다.
내보낸 데이터로 우선순위를 매기려면 아래처럼 시트를 구성해 보세요. 순위 구간과 목표 CTR은 내 사이트 데이터를 보고 직접 입력하는 칸입니다.
| 열 | 내용 | 예시 행 |
|---|---|---|
| A | 검색어 | 서치 콘솔 사용법 |
| B | 노출수 | 15000 |
| C | CTR(소수) | 0.011 |
| D | 평균 게재순위 | 11.2 |
| E | 우선순위 점수(수식) | 아래 수식 입력 |
| H1 / H2 | 순위 하한 / 상한(직접 입력) | [직접 입력] |
| H3 | 목표 CTR(직접 입력, 예: 내 사이트 상위 글의 CTR) | [직접 입력] |
H1, H2, H3 셀에 각각 순위하한, 순위상한, 목표CTR이라는 이름(이름이 지정된 범위)을 붙인 뒤, E2 셀에 아래 수식을 넣고 아래 행으로 복사합니다.
=IF(AND(D2>=순위하한, D2<=순위상한), B2*MAX(목표CTR-C2, 0), 0)
점수가 높은 검색어부터, 해당 페이지의 제목·첫 문단·소제목이 검색 의도에 답하고 있는지 다시 읽어 보며 고쳐 나가면 됩니다.
6단계: Core Web Vitals 보고서로 페이지 속도와 반응성 점검하기
이 단계의 목표는 실제 사용자 데이터 기준으로 느리거나 반응이 늦은 페이지 그룹을 찾는 것입니다.

- 왼쪽 메뉴의 Core Web Vitals를 엽니다.
- 모바일과 데스크톱 차트 옆의 보고서 열기를 눌러 기기별로 들어갑니다.
- URL 그룹이 느림, 개선이 필요함, 빠름 세 가지 상태로 나뉘어 표시됩니다. 표의 행을 클릭하면 같은 문제를 가진 URL 예시를 볼 수 있습니다.
보고서는 실제 사용자 데이터(CrUX)를 바탕으로 LCP, INP, CLS 세 가지 측정항목을 봅니다. 2024년 3월부터 반응성 지표가 FID에서 INP(다음 페인트까지의 상호작용)로 바뀌었기 때문에, FID 기준으로 쓰인 오래된 안내는 현재 화면과 맞지 않습니다. 또 예전에 있던 '페이지 경험' 보고서는 Search Console에서 제공이 종료되어, 지금은 Core Web Vitals 보고서와 HTTPS 보고서를 각각 확인하면 됩니다.
공식 도움말에 나온 상태별 범위는 다음과 같습니다.
| 측정항목 | 빠름 | 개선이 필요함 | 느림 |
|---|---|---|---|
| LCP(최대 콘텐츠 렌더링 시간) | 2.5초 이하 | 4초 이하 | 4초 초과 |
| INP(다음 페인트까지의 상호작용) | 200밀리초 이하 | 500밀리초 이하 | 500밀리초 초과 |
| CLS(누적 레이아웃 변경) | 0.1 이하 | 0.25 이하 | 0.25 초과 |
'사용 가능한 데이터가 없음'이 보인다면 새로 등록한 속성이거나 해당 기기 유형의 사용자 데이터가 충분하지 않다는 뜻입니다. INP가 느림으로 나온다면 클릭이나 탭 뒤에 실행되는 자바스크립트가 길게 메인 스레드를 붙잡고 있지 않은지, 무거운 서드파티 스크립트나 광고 태그가 없는지부터 확인하세요.
7단계: 실적 데이터 내보내기와 BigQuery 대량 데이터 내보내기
이 단계의 목표는 화면에서 보는 데 그치지 않고 데이터를 꺼내 장기간 보관하고 분석하는 것입니다.
가장 간단한 방법은 실적 보고서 오른쪽 위의 내보내기 버튼입니다. 차트와 표 데이터를 Google 스프레드시트, Excel, CSV 형식으로 받을 수 있습니다. 다만 웹 화면의 표와 내보내기 파일은 최대 1,000행까지만 담기 때문에, 롱테일 검색어가 많은 사이트는 전체를 볼 수 없습니다. 정기적으로 내려받은 데이터를 시트에 쌓아 두었다면 엑셀로 대시보드 만드는 방법을 참고해 팀 공유용 화면으로 정리할 수 있고, 어떤 차트로 보여 줄지는 데이터 시각화 개념과 실전 가이드를 함께 보면 도움이 됩니다.
대시보드를 계속 갱신하고 싶다면 Looker Studio의 Search Console 커넥터로 속성을 연결하는 방법도 있습니다.
행 수 한도 없이 원본 데이터를 받으려면 대량 데이터 내보내기를 씁니다. 공식 도움말의 순서는 다음과 같습니다.
- Google Cloud 콘솔에서 프로젝트에 결제를 설정하고 BigQuery API와 BigQuery Storage API를 사용 설정합니다.
- 안내에 따라 Search Console 서비스 계정에 BigQuery 작업 사용자, BigQuery 데이터 편집자 역할을 부여합니다.
- 서치 콘솔 속성의 설정 > 대량 데이터 내보내기로 이동해 Cloud 프로젝트 ID(프로젝트 번호가 아님), 데이터 세트 이름(기본값 searchconsole), 데이터 세트 위치를 입력하고 계속을 누릅니다.
- 구성 후 첫 내보내기가 실행되기까지 최대 48시간이 걸리며, 설정 이전의 과거 데이터는 내보내지지 않습니다.
BigQuery는 무료 사용량을 넘는 저장·쿼리에 요금이 청구되므로, 테이블이 생성된 뒤 파티션 만료 기간을 설정해 두는 것이 좋습니다.
구글 서치 콘솔 7단계 점검표
지금까지의 단계를 빠뜨리지 않았는지 아래 표로 확인하세요.
| 단계 | 핵심 작업 | 완료 확인 신호 |
|---|---|---|
| 1단계 | 속성 추가와 소유권 확인 | 속성 선택기에서 내 속성이 열림 |
| 2단계 | Sitemaps에 사이트맵 제출 | 상태 '성공', 발견된 페이지 수 표시 |
| 3단계 | URL 검사로 중요 페이지 색인 생성 요청 | 요청이 대기열에 제출됨 |
| 4단계 | 페이지 색인 생성 보고서 이유 점검 | 출처가 '웹사이트'인 이유 수정 후 수정 결과 확인 |
| 5단계 | 실적 보고서에서 개선 후보 검색어 선정 | 검색어·페이지 목록과 우선순위 시트 완성 |
| 6단계 | Core Web Vitals 상태 확인 | 모바일·데스크톱 '느림' URL 그룹 원인 파악 |
| 7단계 | 데이터 내보내기 또는 대량 데이터 내보내기 | 정기 백업 시트 또는 BigQuery 데이터 세트 생성 |
검색어 선정부터 이미지가 들어간 SEO 글 작성, 워드프레스 발행, 기존 글 최적화까지 한곳에서 관리하세요. Orova SEO는 2027년 7월 7일까지 무료로 사용할 수 있습니다.
서치 콘솔 운영 중 자주 생기는 문제와 해결
| 증상 | 흔한 원인 | 해결 방법 |
|---|---|---|
| 소유권 확인이 갑자기 해제됨 | 호스팅·DNS 이전 중 TXT 레코드나 HTML 파일 삭제 | 확인용 레코드·파일을 복구하고, 설정 > 소유권 확인에서 확인 방법을 하나 더 추가 |
| 사이트맵 상태가 '가져올 수 없음' | 주소 오타, robots.txt 차단, 로그인·방화벽 차단 | 브라우저와 URL 검사로 주소를 열어 보고 차단 해제 후 다시 제출 |
| Soft 404로 분류됨 | 내용이 거의 없는 페이지가 200 코드를 반환 | 없는 페이지는 404/410 반환, 필요한 페이지는 내용 보강 |
| URL 검사에서 robots.txt 차단으로 표시 | robots.txt의 Disallow 규칙 | 해당 경로를 막는 규칙을 수정하거나 삭제 |
| 지정한 canonical 대신 다른 URL이 표준으로 선택됨 | 내부 링크·사이트맵이 다른 URL을 가리킴 | 메뉴·본문 링크와 사이트맵을 원하는 표준 URL로 통일 |
| 실적 보고서 클릭수와 GA4 세션 수가 다름 | 두 도구의 측정 시점·방식 차이, 동의 거부·추적 코드 누락 | 정상 범위의 차이로 보고 추세 위주로 비교, 추적 코드 설치 상태 점검 |
Orova SEO로 서치 콘솔 검색어를 글 작업으로 잇기
5단계에서 찾은 검색어를 실제 글로 옮기는 일은 손이 많이 갑니다. Orova SEO는 AI가 SEO용 글을 이미지와 함께 쓰고 워드프레스에 발행하며, 기존 글 최적화와 Search Console 수치 확인을 한곳에서 하도록 만든 도구입니다. 내 사이트의 Search Console에서 게재순위 8~30위 구간의 검색어를 우선 후보로 가져오고, 기존 글은 URL을 그대로 둔 채 덮어써서 고칠 수 있습니다. 워드프레스 연결은 플러그인 없이 Application Password를 사용합니다.

새 글을 쓸 검색어를 넣는 순서는 다음과 같습니다.
- Orova SEO 상단의 Write 탭을 엽니다. 검색어 목록에서 각 검색어의 상태(Written, Failed 등)와 발행된 글의 URL을 확인할 수 있습니다.
- 오른쪽 위 + Add keyword를 누릅니다. 검색어가 많다면 옆의 Import from Excel을 쓸 수 있습니다.
- Add keyword 창의 1번 영역에서 Keyword(검색어)와 Project (website)를 고르고, What searchers want on Google에서 검색 의도를 선택합니다.
- 3번 영역 Length and number of images에서 글 길이와 이미지 수를 정하고, 5번 영역 When to publish에서 Publish as soon as possible 또는 Schedule publishing을 고릅니다.
- Add keyword를 누르면 작업이 목록에 추가됩니다.

사이트 기술 상태를 먼저 훑어보고 싶다면, 로그인 없이 링크만 붙여 넣어 기술 점검과 PageSpeed 결과, 도메인 수준 백링크를 확인하는 Orova SEO Check를 함께 써 볼 수 있습니다.
설정을 마친 뒤 확인할 지표
설정과 수정을 마쳤다면 다음 세 가지를 주기적으로 확인합니다.
첫째, 페이지 색인 생성 보고서의 색인 생성된 페이지 수입니다. 사이트가 커지면 이 숫자도 점진적으로 늘어나야 하며, 갑자기 늘거나 줄면 원인을 확인해야 합니다. 수정 결과 확인을 요청했다면 진행 상황과 결과 알림을 함께 살펴봅니다.
둘째, 실적 보고서에서 고친 페이지의 노출수와 평균 게재순위 변화입니다. 고친 날짜를 기록해 두고 같은 길이의 기간을 비교하는 비교 기능으로 전후를 보면 변화가 우연인지 판단하기 쉽습니다.
셋째, Core Web Vitals 보고서의 '빠름' URL 그룹입니다. 수정 후에도 실제 사용자 데이터가 쌓이는 데 시간이 걸리므로, 한두 번의 측정보다 추세를 보세요.
구글 서치 콘솔의 향후 몇 년간 트렌드: 작성자의 견해
AI 요약 영역에서의 노출을 따로 보고 싶다는 요구가 커질 것이라고 생각합니다. 검색 결과 상단에 AI 요약이 자리 잡으면서, 링크를 클릭하지 않고 답을 얻는 검색이 늘고 있다는 이야기가 많습니다. 저는 운영자들이 일반 링크 클릭과 AI 요약 속 인용 노출을 구분해서 보고 싶어 할 것이고, 서치 콘솔이 이 요구에 어떤 식으로든 답하게 될 가능성이 있다고 봅니다. 그때까지는 '내 글이 신뢰할 만한 출처로 인용될 만큼 명확한가'를 스스로 점검하는 것이 현실적인 대비입니다.
사이트맵과 수동 요청 중심의 색인 방식이 바뀔 여지가 있다고 봅니다. 지금 Indexing API는 채용 공고와 라이브 방송 같은 일부 콘텐츠에만 쓰도록 안내되고 있습니다. 콘텐츠 발행 속도가 빨라지면서 CMS와 검색 엔진 사이에 더 직접적인 알림 방식이 필요하다는 목소리도 나올 것입니다. 다만 이것은 Google의 정책 결정에 달린 일이라, 저는 당장은 사이트맵의 lastmod를 정확하게 관리하는 쪽에 힘을 쓰는 것이 낫다고 생각합니다.
사용자 경험 지표의 비중은 꾸준히 이어질 것이라고 봅니다. FID가 INP로 바뀐 것처럼, 측정 방식은 실제 사용자가 느끼는 반응성에 더 가까워지는 방향으로 다듬어져 왔습니다. 그래서 저는 자바스크립트가 무거워져 첫 반응이 늦어지는 사이트라면 콘텐츠만큼이나 성능 관리에도 시간을 배정해야 한다고 생각합니다. 물론 성능 지표가 순위를 결정하는 유일한 요소는 아니라는 점도 함께 기억해야 합니다.
구글 서치 콘솔에 대해 자주 묻는 질문
구글 서치 콘솔에 등록한 뒤 데이터가 보이기까지 얼마나 걸리나요?
새로 추가한 속성은 데이터가 수집·처리될 때까지 며칠이 걸릴 수 있습니다. 소유권을 확인한 직후 보고서가 비어 있어도 정상이므로, 그동안 사이트맵 제출과 홈페이지 URL 검사를 먼저 해 두세요.
사이트맵을 제출했는데도 색인이 되지 않는 이유는 무엇인가요?
사이트맵은 Google에 페이지 위치를 알려 줄 뿐 색인을 보장하지 않습니다. 페이지 색인 생성 보고서에서 해당 URL이 어떤 이유로 분류되어 있는지 확인하고, 이유별로 조치하세요. 새 페이지라면 Google이 크롤링과 색인을 시작하기까지 일주일 정도 걸릴 수 있습니다.
구글 서치 콘솔과 구글 애널리틱스 4(GA4)의 차이점은 무엇인가요?
서치 콘솔은 Google 검색 안에서의 노출수, 클릭수, 평균 게재순위, 색인 상태처럼 방문 전 데이터를 보여 줍니다. GA4는 사이트에 들어온 뒤 방문자가 어떤 페이지를 보고 어떤 행동을 했는지를 측정합니다.
색인 생성 요청을 같은 URL에 여러 번 눌러도 되나요?
같은 URL을 반복해서 요청해도 처리가 빨라지지 않습니다. 하루 요청 횟수는 속성별로 제한되어 있으므로, 한 번 요청한 뒤에는 기다리고 남은 횟수는 다른 중요한 페이지에 쓰는 것이 좋습니다.
AI로 작성한 콘텐츠도 서치 콘솔에서 정상적으로 색인되나요?
Google은 작성 방식보다 콘텐츠가 사람에게 유용한지를 중요하게 본다고 안내하고 있습니다. 다만 다른 글을 단순히 요약하거나 옮긴 수준이라면 '크롤링됨 - 현재 색인이 생성되지 않음'처럼 색인되지 않는 상태로 남을 수 있습니다.
도메인 속성과 URL 접두사 속성 중 어떤 것을 골라야 하나요?
하위 도메인과 http/https를 모두 한 번에 보고 싶다면 도메인 속성이 편합니다. 특정 경로(예: 언어별 폴더)나 프로토콜만 따로 보거나, DNS를 수정할 권한이 없다면 URL 접두사 속성을 고르세요. 두 속성을 함께 추가해 두는 것도 가능합니다.
구글 서치 콘솔, 어디서부터 시작해야 할까요?
사이트를 막 연 운영자라면 오늘은 1~3단계까지만 하세요. 도메인 속성을 추가해 소유권을 확인하고, 사이트맵을 제출하고, 홈페이지를 URL 검사로 요청해 두면 됩니다.
운영한 지 시간이 지났는데 검색 유입이 정체되어 있다면 5단계부터 시작하세요. 실적 보고서에서 노출은 많지만 클릭이 적은 검색어 몇 개를 고르고, 해당 페이지의 제목과 첫 문단이 그 검색어에 답하는지 다시 읽어 보는 것이 출발점입니다.
페이지가 많은 쇼핑몰이나 기업 사이트라면 4단계의 페이지 색인 생성 보고서를 먼저 보세요. 출처가 '웹사이트'인 이유 가운데 noindex나 canonical 설정 실수처럼 중요한 페이지를 막고 있는 문제부터 고치는 것이 순서입니다. 어느 경우든 구글 서치 콘솔은 한 번 설정하고 끝내는 도구가 아니라, 정기적으로 열어 보는 습관이 중요합니다.
AI Agents로 비즈니스를 운영하세요
Orova는 언제나 깨어 있는 Biz AI Agent입니다 — 업무를 계획하고, 실행하고, 최적화해 드립니다.
시간은 아끼고, 생산성은 높이세요.