Search Console URL 검사, CDP로 연결해 기존 탭 재사용·색인 생성 요청—입력칸 0은 왜 생겼을까?
입력칸이 보이는데 자동화에서는 크기 0으로 잡히는 이유를 화면 상태에서 찾아, 로그인된 같은 탭을 재사용하는 점검 순서를 얻는다.
로그인 상태를 보존한 브라우저 탭은 이전 작업의 모바일 에뮬레이션까지 남길 수 있으므로 반복 실행 전에 화면 크기와 입력칸 상태를 함께 확인할 필요가 있다.
읽기 전에 확인할 근거
Search Console URL 검사 자동화가 멈춘 원인은 로그인이나 URL이 아니라 기존 9222 탭에 남아 있던 390×844 모바일 에뮬레이션이었어요. 새 탭을 만들지 않고 같은 탭의 뷰포트를 복원한 뒤 홈·캘린더·판별기 3개 URL을 우선순위 크롤링 대기열에 넣었지만, 이것이 색인을 보장하지는 않아요.
처음에는 이상해 보였어요. Search Console 탭은 열려 있었고 로그인도 유지됐는데, 자동화가 URL 검사 입력칸의 크기를 재면 너비와 높이가 0으로 나왔거든요. 공식 안내만 보면 화면 위 검색창에 URL을 넣으면 된다고 설명하지만, 이미 열려 있는 탭에 어떤 화면 설정이 남아 있는지는 별도로 확인해야 했어요.
입력칸은 있었는데 왜 크기가 0이었을까
요소를 찾았다는 것과 실제로 입력할 수 있다는 것은 같은 말이 아니에요. 이번 탭에서는 URL 검사 입력칸이 문서 안에 존재했지만, 390×844 모바일 화면처럼 동작하는 상태가 남아 있어 화면 배치상 크기가 0으로 측정됐어요.
쉽게 말하면 가게 주소는 제대로 찾았는데 셔터가 내려가 있는 상황과 비슷해요. 자동화는 입력칸의 주소에 해당하는 요소까지 찾았지만, 실제로 누르고 글자를 넣을 공간이 있는지 확인하는 단계에서 멈춘 셈이죠.
- 연결 대상: 9222 포트에서 이미 열려 있던 Search Console 탭
- 남아 있던 상태: 390×844 모바일 에뮬레이션
- 관찰된 실패: URL 검사 입력칸의 측정 크기 0
- 분리한 원인: 로그인 만료나 잘못된 URL이 아니라 기존 탭의 화면 상태
이 차이를 모르고 입력 명령만 다시 보내면 같은 실패가 반복돼요. 선택자를 바꾸거나 기다리는 시간을 늘리기 전에, 현재 탭의 화면 크기와 입력칸의 실제 영역부터 확인하는 편이 원인에 더 가까웠어요.
CDP로 연결해도 새 탭을 만들 필요는 없었어요
Playwright의 공식 문서에는 기존 Chromium 브라우저에 CDP로 연결하는 방법이 나와 있어요. 연결한 뒤 기본 브라우저 컨텍스트에서 이미 열린 페이지를 가져올 수 있으므로, 로그인된 Search Console 탭을 찾아 재사용하는 흐름을 만들 수 있어요.
CDP는 어려운 이름이지만 역할은 단순해요. 이미 켜져 있는 크롬과 자동화 도구 사이에 대화 통로를 여는 방식이에요. 이번 작업에서도 브라우저를 새로 실행하거나 Search Console 탭을 하나 더 만들지 않았어요.
다만 CDP 연결 자체가 탭의 화면 상태를 초기화해 주는 것은 아니에요. 기존 탭을 재사용하면 로그인과 현재 페이지뿐 아니라 앞선 작업에서 사용한 모바일 에뮬레이션도 함께 남을 수 있어요. 이번 실패에서 놓치기 쉬웠던 부분이 바로 여기였어요.
Playwright는 CDP 연결이 Chromium 계열에서 지원되며, 일반 Playwright 연결보다 기능 충실도가 낮다고 안내해요. 그래서 연결 성공을 전체 작업 성공으로 취급하기보다 다음 조건을 따로 확인하는 게 안전해요.
- 열린 탭 가운데 주소가 Search Console인 탭을 정확히 골랐는지
- 현재 탭에 모바일 뷰포트나 터치 에뮬레이션이 남아 있는지
- URL 검사 입력칸의 너비와 높이가 0보다 큰지
- 입력칸이 보이기만 하는 상태가 아니라 실제 입력 가능한 상태인지
같은 탭을 복원한 뒤 3개 URL을 대기열에 넣었어요
수정은 새 탭 생성이 아니라 기존 탭의 뷰포트 복원이었어요. 화면을 데스크톱 작업에 맞는 상태로 되돌린 뒤 URL 검사 입력칸을 다시 측정하고, 입력 가능한 상태인지 확인했어요.
그다음 홈·캘린더·판별기 3개 URL을 우선순위 크롤링 대기열에 추가했어요. 여기서 대기열은 어떤 URL부터 검사할지 정리한 자동화 작업 목록이에요. Google이 실제로 크롤링하거나 색인했다는 완료 목록은 아니에요.
- 9222에 연결한 뒤 새 페이지를 만들지 않고 열린 탭 목록을 확인했어요.
- 주소를 기준으로 기존 Search Console 탭을 골랐어요.
- 390×844 모바일 에뮬레이션이 남은 상태를 확인했어요.
- 같은 탭의 뷰포트를 복원했어요.
- URL 검사 입력칸의 실제 크기와 입력 가능 여부를 다시 확인했어요.
- 홈·캘린더·판별기 순으로 우선순위 크롤링 대기열에 넣었어요.
이 순서의 장점은 로그인된 탭을 버리지 않으면서도 이전 작업의 화면 설정을 그대로 믿지 않는다는 데 있어요. 연결 여부, 탭 선택, 화면 상태, 입력 가능 여부를 서로 다른 검사로 나누면 어디에서 실패했는지 기록하기도 쉬워져요.
색인 생성 요청과 색인 완료는 다릅니다
Google은 URL 검사 도구를 이용해 자신이 관리하는 개별 URL의 재크롤링을 요청할 수 있다고 안내해요. 하지만 요청했다고 검색결과에 즉시 포함되거나 반드시 색인되는 것은 아니라고 분명히 밝혀요.
같은 URL을 여러 번 요청한다고 더 빨리 크롤링되는 것도 아니에요. 개별 URL 제출에는 할당량이 있고, 많은 URL을 알릴 때는 사이트맵을 이용하는 방법도 공식 문서에서 안내하고 있어요.
- 자동화 대기열 추가: 검사할 URL과 순서를 내부 작업 목록에 기록한 상태
- 색인 생성 요청: Search Console URL 검사 도구에서 재크롤링을 요청한 상태
- 크롤링: Google이 해당 URL을 다시 방문한 상태
- 색인: Google 시스템이 페이지를 검색 대상에 포함한 상태
이 네 단계는 같은 완료 표시가 아니에요. 이번 기록에서 확인된 결과는 홈·캘린더·판별기 3개가 우선순위 대기열에 들어갔다는 것까지예요. 이후 크롤링 시점과 색인 여부는 별도로 확인해야 해요.
다음 실행에서 먼저 확인할 순서
로그인된 브라우저를 계속 재사용하려면 탭의 존재보다 탭의 현재 상태를 먼저 검사하세요. 특히 앞선 작업에서 모바일 화면을 시험했다면 뷰포트 확인을 입력 동작보다 앞에 두는 편이 좋아요.
- CDP 연결 뒤 기본 컨텍스트의 열린 페이지 목록을 가져와요.
- 주소와 제목을 함께 보고 기존 Search Console 탭을 선택해요.
- 현재 뷰포트와 모바일 에뮬레이션 여부를 기록해요.
- URL 검사 입력칸의 실제 크기가 0보다 큰지 확인해요.
- 조건을 통과한 경우에만 URL 입력과 다음 단계로 넘어가요.
- 대기열 추가, 요청 시도, 요청 결과, 이후 색인 확인을 서로 다른 기록으로 남겨요.
이 방법은 Search Console 속성의 소유자나 전체 사용자 권한이 있는 계정에 맞아요. 관리하지 않는 URL에는 색인 생성을 요청할 수 없어요. Firefox나 WebKit 탭을 같은 방식으로 연결하려는 경우에도 맞지 않아요. Playwright의 CDP 연결은 Chromium 기반 브라우저를 대상으로 하기 때문이에요.
확인한 기준
2026년 8월 12일 기준으로 Google Search Central의 재크롤링 안내에서 개별 URL 요청 방법, 요청 권한, 반복 요청의 한계와 색인 비보장 조건을 확인했어요. Playwright 공식 문서에서는 기존 Chromium에 CDP로 연결하는 방법과 기본 컨텍스트의 열린 페이지를 가져오는 경로를 대조했어요.
- Google Search Central의 URL 재크롤링 요청 안내
- Playwright의 기존 Chromium CDP 연결 안내
- Google Search Console의 단일 페이지 검사 안내
390×844 모바일 에뮬레이션과 입력칸 크기 0, 같은 탭의 복원, 홈·캘린더·판별기 3개 대기열 추가는 제공된 실제 작업 기록을 기준으로 했어요. 계정 화면과 세 URL의 이후 크롤링·색인 결과는 확인 범위에 포함하지 않았어요.
댓글
댓글 쓰기
질문은 자유롭게 남겨주세요. 광고성 댓글, 비방, 개인정보가 포함된 댓글은 삭제될 수 있습니다.