Search Console 속성에 URL이 없음, 도메인 속성과 URL 접두어 속성 차이—왜 티스토리 두 건은 따로 접수됐을까?

먼저 얻을 답

속성 불일치로 멈춘 티스토리 URL을 올바른 사이트 속성으로 다시 보내고 접수 여부까지 구분할 수 있다.

여러 사이트를 연속 처리할수록 이전 작업에서 선택한 속성이 남아 다음 URL과 뒤섞이기 쉬우므로 요청 전에 속성 범위를 확인할 필요가 있다.

읽기 전에 확인할 근거

근거 1Google은 검사 URL이 현재 열려 있는 속성에 포함되어야 한다고 안내한다.
근거 2도메인 속성과 URL 접두어 속성은 포함하는 프로토콜·호스트 범위가 다르다.
근거 3제공된 작업 기록에서는 사이트별 URL 접두어 속성으로 바꾼 뒤 두 건의 요청 접수를 확인했다.
사이트별 Search Console 속성을 분리하고 티스토리 두 건의 요청 접수를 확인하는 작업 장면

Search Console 속성에 URL이 없음 오류는 검사할 주소가 현재 선택한 속성의 범위 밖에 있을 때 먼저 확인해야 해요. 1eyeview 도메인 속성에서 티스토리 주소를 검사하지 말고, 해당 티스토리 사이트의 정확한 URL 접두어 속성으로 바꿔 요청해야 합니다.

제공된 작업 기록에서는 이 방식으로 두 건의 요청 접수까지 확인했어요. 다만 여기서 확인된 사실은 ‘요청이 받아들여졌다’는 데까지예요. Google 색인 완료나 검색 노출까지 끝났다는 의미는 아닙니다.

오류는 URL보다 선택한 속성에서 시작됐어요

1eyeview 속성과 티스토리 URL 카드가 서로 다른 범위임을 확인하는 장면

자동화가 처음 멈춘 지점은 1eyeview 도메인 속성에서 티스토리 글 주소를 검사한 순간이었어요. 주소를 잘못 복사한 문제처럼 보일 수 있지만, 먼저 봐야 할 것은 현재 열려 있던 속성이었습니다.

속성은 쉽게 말해 Search Console 안의 ‘주소 구역’이에요. sc-domain:1eyeview.com은 1eyeview.com과 그 하위 주소를 담는 구역이지, 별개의 티스토리 주소까지 담는 공용 작업함은 아니에요.

아파트 A동 우편함을 열어 놓고 B동 주소의 등기를 찾는 상황을 떠올리면 쉬워요. 등기 자체가 잘못된 것이 아니라 찾아본 주소 구역이 달랐던 거예요. 자동화에서 URL을 정확히 입력해도 선택한 속성이 다르면 이 단계에서 멈출 수 있습니다.

공식 안내에서 먼저 확인한 한 문장

Google 공식 도움말을 보며 현재 속성의 포함 범위를 확인하는 장면

Google의 URL 검사 도움말은 검사할 전체 URL이 현재 열려 있는 속성에 포함되어야 한다고 안내해요. 이번 오류를 판단하는 가장 직접적인 기준입니다.

검사 순서는 URL 입력보다 속성 확인이 먼저예요. 여러 사이트를 연속 처리할 때는 아래 세 가지를 한 묶음으로 비교하면 됩니다.

  • 검사할 URL이 https로 시작하는지
  • 주소의 호스트가 1eyeview.com인지 별도의 티스토리 주소인지
  • 현재 선택한 Search Console 속성이 그 URL 전체를 포함하는지

Google은 URL 검사를 통해 색인 상태와 색인 생성 가능 여부를 확인할 수 있다고 설명해요. 문제가 해결된 뒤에는 실시간 URL 테스트를 할 수 있고, 색인 생성 요청은 선택적으로 진행할 수 있습니다. 소유한 속성별 요청 횟수에는 제한도 있어요.

도메인 속성과 URL 접두어 속성은 담는 범위가 달라요

도메인 속성과 URL 접두어 속성의 범위를 수납함으로 비교하는 장면

도메인 속성은 한 도메인의 여러 프로토콜과 하위 도메인을 넓게 묶어요. 반면 URL 접두어 속성은 등록한 시작 주소와 정확히 맞는 URL만 담습니다.

  • 도메인 속성: example.com을 등록하면 그 도메인의 http·https와 여러 하위 도메인을 함께 포함해요.
  • URL 접두어 속성: https://example.com/을 등록하면 그 접두어로 시작하는 주소만 포함해요.
  • 별도 플랫폼 주소: 1eyeview.com과 티스토리 주소처럼 호스트가 다르면 같은 도메인 속성에 자동으로 묶이지 않아요.

여기서 많이 놓치는 부분은 ‘도메인 속성이 넓다’는 말을 ‘내가 운영하는 모든 사이트를 담는다’로 이해하는 거예요. 넓다는 말은 등록한 도메인 안에서 넓다는 의미예요. 운영자가 같아도 주소가 다른 사이트까지 포함하지는 않습니다.

티스토리 사이트를 URL 접두어 속성으로 등록할 때는 실제 공개 주소의 프로토콜과 호스트를 그대로 맞춰야 해요. https와 http, 하위 도메인, 맞춤 도메인이 달라지면 포함 범위도 달라질 수 있습니다.

사이트별 속성으로 바꾸고 두 건을 다시 보냈어요

티스토리 사이트별 속성을 선택해 URL 요청을 한 건씩 다시 보내는 장면

수정은 자동화 전체를 다시 시작하는 방식이 아니라 실패한 URL의 속성 선택만 바로잡는 순서로 진행됐어요. 제공된 기록상 두 URL을 각각 해당 사이트의 URL 접두어 속성으로 바꾼 뒤 색인 생성 요청 접수를 확인했습니다.

  1. 실패한 URL에서 https:// 다음 호스트 부분을 확인해요.
  2. Search Console 속성 목록에서 그 주소를 포함하는 URL 접두어 속성을 선택해요.
  3. 전체 URL을 다시 검사해 속성 불일치 오류가 사라졌는지 봐요.
  4. 페이지 상태를 확인한 뒤 색인 생성 요청을 한 건씩 진행해요.
  5. 자동화 기록에는 ‘요청 접수’와 ‘색인 확인’을 서로 다른 상태로 남겨요.

여러 사이트를 계속 처리한다면 URL마다 선택할 속성을 미리 짝지어 두는 편이 안전해요. 예를 들어 입력 목록에 URL만 두지 말고 해당 URL이 속할 Search Console 속성도 함께 관리하는 방식이에요. 두 값의 호스트가 맞지 않으면 검사창에 넣기 전에 멈추게 할 수 있습니다.

접수됐다는 말과 색인됐다는 말은 달라요

두 건의 접수 표시와 이후 색인 확인이 남았음을 구분하는 장면

두 건의 요청이 접수됐어도 Google이 두 페이지의 색인을 끝냈다고 단정하면 안 돼요. 요청은 Google에 다시 확인해 달라고 전달한 단계이고, 실제 크롤링과 색인 판단은 그다음에 진행됩니다.

Google 공식 안내도 ‘Google에 등록되어 있음’이 검색결과 표시를 보장하는 것은 아니라고 설명해요. 반대로 요청 직후 상태가 바뀌지 않았다고 해서 같은 요청을 연달아 반복할 이유도 없습니다.

후속 확인에서는 URL 검사 결과의 페이지 색인 생성 항목을 보세요. Google이 URL을 발견했는지, 크롤링할 수 있었는지, 표준 URL을 무엇으로 판단했는지를 나눠 확인해야 해요.

속성을 고쳐도 해결되지 않는 경우가 있어요

현재 속성과 URL이 정확히 맞는데 검사가 계속 실패한다면 속성 불일치만의 문제는 아니에요. 다음 조건을 따로 확인해야 합니다.

  • 해당 Search Console 속성의 소유권이나 사용 권한이 없는 경우
  • 페이지가 로그인을 요구하거나 외부에서 열리지 않는 경우
  • robots 설정이나 noindex 지시로 검색엔진 접근을 막은 경우
  • 검사한 URL 대신 다른 주소가 표준 URL로 선택된 경우
  • 티스토리 기본 주소와 맞춤 도메인을 혼용한 경우

Blogger 공식 설정 도움말에는 ‘크롤러 및 색인 생성’ 아래 Google Search Console 연결 메뉴가 안내돼 있어요. 다만 이 문서는 Blogger 설정용입니다. 티스토리의 관리 메뉴나 소유권 확인 절차를 설명하는 근거로 바꿔 읽으면 안 돼요.

확인한 기준

2026년 8월 16일 기준으로 Google Search Console 도움말에서 URL 검사 대상이 현재 속성에 포함되어야 한다는 조건과 도메인 속성·URL 접두어 속성의 범위를 대조했어요. 2026년 8월 16일 블로그 전용 Chrome의 Search Console 화면에서 티스토리 두 주소의 요청 접수를 직접 확인했고, 세 번째 주소는 일일 할당량 초과로 접수되지 않았습니다.

이 글이 필요한 경우여러 사이트의 색인 요청을 자동화하다 다른 사이트 속성에서 URL을 검사해 작업이 멈춘다.
이 방법이 맞지 않는 경우속성은 맞지만 페이지 자체가 크롤링 차단 또는 noindex 상태이거나 소유권 권한이 없는 경우

내 URL이 포함되는 속성부터 확인하기

댓글

댓글 쓰기

질문은 자유롭게 남겨주세요. 광고성 댓글, 비방, 개인정보가 포함된 댓글은 삭제될 수 있습니다.

이 블로그의 인기 게시물

CSV 정리 자동화, 삭제 기능보다 감사 보고서를 먼저 만든 이유

이미지
CSV 정리 자동화를 만들 때 처음 떠올리기 쉬운 기능은 ‘중복을 지운다’입니다. 그런데 실제 파일을 맡기는 사람 입장에서는 삭제보다 먼저 확인할 것이 있습니다. 어떤 행이 왜 빠졌는지, 원본은 그대로인지, 한 파일이 실패했을 때 다른 파일까지 멈추지는 않았는지입니다. 그래서 이번에 만든 CSV Audit Cleaner 는 삭제 버튼보다 감사 보고서를 중심에 두었습니다. 2026년 7월 30일 정식판을 다시 빌드해 Windows에서 실행했고, 4행짜리 표본이 2행으로 정리되는 과정과 빈 행 1개·중복 1개·실패 0건을 실제 결과로 확인했습니다. 공개 판매본 기준 자동 검사는 32개 모두 통과했습니다. 파일을 깨끗하게 만드는 것과 설명 가능하게 만드는 것은 달랐습니다 공백을 자르고 빈 행을 버리는 코드는 짧게 만들 수 있습니다. 문제는 결과만 보면 사용자가 ‘원래 4행이었는데 왜 2행이 됐지?’라고 묻게 된다는 점입니다. 그 질문에 답하지 못하면 자동화는 빨라도 믿고 반복하기 어렵습니다. 프로그램은 실행할 때마다 새 결과 폴더를 만들고, 정리된 CSV와 함께 report.html , summary.json , run_log.jsonl 을 남깁니다. HTML 보고서에서는 파일별 입력 행·출력 행·빈 행·중복 행·실패 수를 바로 볼 수 있습니다. 로그와 요약 파일은 나중에 다른 작업과 연결할 때 쓰도록 분리했습니다. 원본 파일을 덮어쓰지 않는 것도 같은 이유입니다. 실행 전후 원본의 SHA-256을 기록해 ‘정리 과정에서 원본이 바뀌지 않았는지’를 대조할 수 있게 했습니다. 보기 좋은 결과보다 되돌아갈 수 있는 결과를 먼저 만든 셈입니다. 클라우드 업로드 대신 이 PC 안에서만 처리하도록 범위를 잘랐습니다 요즘은 CSV를 대화형 서비스에 올려 분석하는 방법도 많습니다. 다만 고객 목록, 주문 내역, 내부 기록처럼 외부 업로드 여부를 먼저 따져야 하는 파일도 있습니다. 이 도구는 브라우저처럼 보이는 화면을 쓰지만 인터넷 사이트가 아니라 이 PC의 12...
자세한 내용 보기

뤼튼 무료 범위와 크랙 결제, 무료 AI와 유료 콘텐츠를 나눠 보세요

이미지
뤼튼 무료 범위와 크랙 결제, 무료 AI와 유료 콘텐츠를 나눠 보세요에서 핵심은 한 가지입니다. 뤼튼 AI 사용, 크랙 콘텐츠, 크래커 결제, 환불 조건, 앱·웹 결제 차이를 분리해서 확인하게 한다. 확인일은 2026-07-29입니다. 이 글은 기존 글의 반복 설명과 강한 단정을 줄이고, 독자가 실제로 확인할 순서만 남깁니다. 먼저 오해를 끊을 기준 뤼튼 메인 서비스와 크랙은 같은 통합 회원 체계와 연결될 수 있지만 무료 AI 사용과 유료 콘텐츠 결제는 구분해야 한다. 첫 기준은 공식 안내 에서 확인합니다. 화면이나 공지에서 말하는 범위를 넘어 결론을 확장하지 않는 것이 중요합니다. 두 번째로 확인할 공식 경로 크랙 고객센터는 크래커 결제와 환불 조건을 별도 안내하므로 무료 AI 이용 범위와 같은 의미로 보면 안 된다. 관련 조건은 관련 공식 경로 에서도 다시 봅니다. 서비스·제도·도구가 다르면 같은 말처럼 보여도 처리 기준이 달라질 수 있습니다. 결과가 달라지는 예외 앱스토어·구글플레이·웹 결제는 환불 요청 경로와 처리 조건이 달라질 수 있다. 추가 확인은 추가 확인 경로 에서 합니다. 한 화면의 결과만으로 모든 조건을 확정하지 않습니다. 실행 전에 멈춰 볼 항목 무료라는 표현은 특정 모델, 콘텐츠, 크레딧, 저장 기능, 결제 상품까지 모두 무료라는 뜻이 아니다. 뤼튼 무료 범위를 크랙 유료 콘텐츠와 섞지 않고, 결제 전 무료·유료·환불 조건을 각각 확인하게 한다. 바로 적용할 순서 뤼튼은 무료라고 들었는데 크랙 결제와 유료 전환 기능이 어디서 생기는지 헷갈린다. 뤼튼 AI 사용, 크랙 콘텐츠, 크래커 결제, 환불 조건, 앱·웹 결제 차이를 분리해서 확인하게 한다. 공식 화면, 약관, 도움말, 계정 설정처럼 직접 확인할 수 있는 근거를 먼저 엽니다. 날짜, 금액, 계정 상태, 파일 보관, 권한, 동의처럼 개인마다 달라지는 값은 본인 화면에서 다시 확인합니다. 기록으로 남길 것 확인한 공식 페이지 이름과 확인일을 적...
자세한 내용 보기

ChatGPT 대화 기록 삭제와 학습 제외, 임시채팅까지 따로 봐야 합니다

이미지
ChatGPT 대화 기록 삭제와 학습 제외, 임시채팅까지 따로 봐야 합니다에서 핵심은 한 가지입니다. 대화 삭제, 모델 개선 설정, 임시채팅, 메모리·개인화, 파일 보관을 서로 다른 설정으로 분리한다. 확인일은 2026-07-29입니다. 이 글은 기존 글의 반복 설명과 강한 단정을 줄이고, 독자가 실제로 확인할 순서만 남깁니다. 먼저 오해를 끊을 기준 OpenAI 도움말 기준 데이터 컨트롤은 대화가 모델 개선에 쓰이는지 선택하는 설정을 제공한다. 첫 기준은 공식 안내 에서 확인합니다. 화면이나 공지에서 말하는 범위를 넘어 결론을 확장하지 않는 것이 중요합니다. 두 번째로 확인할 공식 경로 대화 삭제와 보관은 기록 목록 관리이고, 모델 개선 사용 여부 설정과 같은 동작으로 보면 안 된다. 관련 조건은 관련 공식 경로 에서도 다시 봅니다. 서비스·제도·도구가 다르면 같은 말처럼 보여도 처리 기준이 달라질 수 있습니다. 결과가 달라지는 예외 임시채팅은 기록에 저장되지 않고 모델 학습에 쓰이지 않지만 일정 기간 안전 모니터링을 위해 보관될 수 있다. 추가 확인은 추가 확인 경로 에서 합니다. 한 화면의 결과만으로 모든 조건을 확정하지 않습니다. 실행 전에 멈춰 볼 항목 메모리와 개인화 설정, 프로젝트·파일 보관 정책은 대화 삭제와 별도로 확인해야 한다. ChatGPT 대화 삭제를 학습 제외와 같은 말로 쓰지 않고, 데이터 컨트롤·임시채팅·기록 삭제·메모리를 분리한다. 바로 적용할 순서 ChatGPT 대화 기록을 지우면 모델 학습에서도 완전히 빠지는지, 임시채팅은 어떻게 다른지 헷갈린다. 대화 삭제, 모델 개선 설정, 임시채팅, 메모리·개인화, 파일 보관을 서로 다른 설정으로 분리한다. 공식 화면, 약관, 도움말, 계정 설정처럼 직접 확인할 수 있는 근거를 먼저 엽니다. 날짜, 금액, 계정 상태, 파일 보관, 권한, 동의처럼 개인마다 달라지는 값은 본인 화면에서 다시 확인합니다. 기록으로 남길 것 확인한 공식 페이지 이름과 ...
자세한 내용 보기