A Google 크롤러는 Google가 콘텐츠를 발견하고 이해할 수 있도록 웹페이지 및 기타 리소스를 요청하는 소프트웨어입니다. Googlebot은 Google 검색과 관련된 주요 크롤러입니다. Googlebot의 방문은 Google가 무언가를 가져왔다는 의미입니다. 페이지가 색인화되었거나 특정 검색어에 대해 순위가 매겨진다는 의미는 아닙니다.
유용한 순서는 발견 → 크롤링 → 프로세스 → 인덱스 → 제공입니다. 사이트 소유자의 경우 각 단계마다 다른 증거가 필요합니다. 정확한 URL부터 시작하여 가져올 수 있는지 확인하고 자체 Search Console 속성을 사용하여 Google가 이에 대해 보고하는 내용을 조사하세요.
Google봇이 방문할 때 수행하는 작업
A 크롤러는 브라우저가 페이지를 요청하는 것과 마찬가지로 HTTP 요청을 보냅니다. 서버는 상태 코드, 헤더 및 가능한 경우 콘텐츠를 반환합니다. Google는 JavaScript 및 스타일시트와 같이 페이지를 렌더링하는 데 필요한 리소스를 가져올 수도 있습니다. 서버 로그는 요청을 기록합니다. Google가 콘텐츠에 관해 내리는 모든 결정을 공개하지는 않습니다.
Google에서는 Googlebot 스마트폰과 Googlebot Desktop에 대해 설명합니다. 사용자 에이전트 헤더는 크롤러 하위 유형을 식별하지만 둘 다 robots.txt에서 동일한 Googlebot 토큰을 사용합니다. 데스크탑 브라우저에서 페이지가 완전해 보인다고 해서 Google의 모바일 크롤러에서 페이지가 작동한다고 가정하지 마십시오. 모바일 콘텐츠와 접속 조건도 확인해 보세요.
발견부터 검색결과까지 페이지를 따라가세요
Google 그룹 크롤링, 색인 생성 및 검색을 검색합니다. 해당 설명 내에서 검색과 처리를 분리하면 문제 해결에 도움이 됩니다. 아래 단계는 교육 모델이며, 발견된 모든 URL이 이를 통해 진행된다는 약속은 아닙니다. Google의 검색 작동 방식 가이드에서는 크롤링, 색인 생성 및 결과 표시가 보장되지 않는 이유를 설명합니다.
| Stage | 이것이 귀하에게 의미하는 바 page |
|---|---|
| Discover | Google는 링크나 링크를 통해 URL이 존재한다는 것을 학습합니다. sitemap. |
| Crawl | Google에 URL을 요청하고 접속하면 응답을 받습니다. 성공합니다. |
| Process | Google는 콘텐츠를 분석하고 이해할 수 있도록 페이지를 렌더링할 수 있습니다. it. |
| Index | Google는 중복을 포함하여 검색 가능한 인덱스의 콘텐츠를 고려합니다. Handling. |
| Serve | Google는 특정 검색에 대한 결과를 선택합니다. 색인이 생성된다고 해서 대상 쿼리에 대한 가시성이 보장되는 것은 아닙니다. |
브라우저가 새 가이드를 올바르게 표시한다고 가정합니다. 그러면 귀하의 브라우저 조건 하에서 한 번의 성공적인 방문이 이루어집니다. Google에 의한 검색, Google의 네트워크에서 액세스 또는 해당 인덱스에 포함을 설정하지 않습니다. 개발자에게 문제를 보고할 때 이러한 질문을 별도로 보관하세요.
도움말 Google 실제로 색인을 생성하려는 URL을 찾으세요
중요한 페이지에 관련 있고 접근 가���한 페이지의 유용한 내부 링크를 제공하세요. 탐색에서 숨겨져 있고 관련 콘텐츠에서 링크되지 않은 가이드는 설정된 주제에 연결된 가이드보다 찾기가 더 어렵습니다. 독자도 목적지를 이해할 수 있도록 설명적인 링크 텍스트를 사용하세요.
A 사이트맵은 또 다른 검색 경로를 제공합니다. Google의사이트맵 문서는 대규모 사이트, 새로운 사이트 및 링크를 통해 검색하기 어려운 콘텐츠에 대한 유용성을 설명합니다. 사이트맵에 포함한다고 해서 크롤링이나 색인 생성이 보장되는 것은 아닙니다.
가이드를 게시할 때 기본 URL이 올바른 사이트맵에 표시되고 사이트맵을 가져올 수 있는지 확인하세요. SearchVector의 Sitemap Analyser는 사이트맵 검토의 시작점입니다. 출력을 사이트맵 증거로 처리한 다음 개별 페이지를 별도로 확인하세요. 사이트맵 항목은 차단된 페이지를 복구할 수 없습니다.
올바른 컨트롤을 선택하세요: robots.txt, noindex 또는 canonical
이 컨트롤은 다양한 질문에 답합니다. 의도적인 게시 변경으로 인해 예상치 못한 검색 결과가 생성되는 일반적인 이유는 이들을 혼동하는 것입니다.
- robots.txt는 크롤링을 제어합니다. 허용 안 함 규칙은 호환 크롤러에게 일치하는 콘텐츠를 요청하지 않도록 지시합니다. Google가 다른 곳에서 이에 대해 알게 되면 차단된 URL이 검색에 계속 나타날 수 있습니다.
- noindex는 인덱싱을 제어합니다. Google가 페이지나 HTTP 헤더에서 noindex 지시문을 보려면 크롤링을 허용해야 합니다. noindex를 추가하는 동안 URL을 차단하면 Google가 명령을 읽는 것을 방지할 수 있습니다.
- A canonical은 선호하는 버전을 식별합니다. 중복되거나 유사한 페이지에 대한 신호이며 액세스 제어나 보장된 명령이 아닙니다.
Google는 noindex 지침에 크롤링 요구 사항을 문서화하고 정규화 가이드에 신호와 선택 간의 차이를 문서화합니다. 비공개여야 하는 콘텐츠에는 적절한 액세스 보호가 필요합니다. Robots.txt는 공개적으로 읽을 수 있으며 보안 경계가 아닙니다.
로봇 규칙을 변경하기 전에 정확한 URL과 의도한 크롤러를 테스트하세요. SearchVector의 Robots.txt Tester가 해당 검토를 지원할 수 있습니다. 전반적인 "허용" ��과를 색인 가능성의 증거로 해석하기보다는 조사 중인 규칙을 기록하십시오.
기사를 다시 쓰기 전에 답변을 읽어보세요
A 페이지는 쓰기가 우수하더라도 액세스 단계에서 실패할 수 있습니다. 첫 번째 응답뿐만 아니라 리디렉션과 최종 목적지도 확인하세요. 성공적인 HTTP 상태는 요청이 해당 수준에서 성공했음을 의미합니다. 페이지의 유용성이나 색인 생성 적격성을 인증하지는 않습니다.
Google의 HTTP 상태 안내는 성공적인 응답, 리디렉션, 클라이언트 오류 및 서버 오류를 구별합니다. 지속적인 서버 오류는 크롤링에 영향을 줄 수 있습니다. 성공적인 상태로 반환된 오류 메시지는 오해의 소지가 있는 결과를 생성할 수도 있으며, Google이 오류와 유사한 페이지를 인식할 때 종종 소프트 404로 설명됩니다.
집중된 첫 번째 패스의 경우 SearchVector의 웹 페이지 크롤러를 사용하여 크롤링 가능성 신호를 검토한 다음 이를 서버 및 Google 증거와 비교합니다. 타사 크롤러는 Google봇이 아닙니다. 네트워크, 사용자 에이전트 및 렌더링의 차이점은 두 검사가 일치하지 않는 이유를 설명할 수 있습니다.
작동한 예: 출시 후에도 여전히 가이드가 차단됨
이는 고객 크롤링 로그가 아닌 가상의 진단 연습입니다. /guides/packing-list을 실행하고 가이드 허브에서 연결하여 사이트맵에 추가한다고 상상해 보세요. 일반 브라우저는 의도한 기사를 수신하지만 로봇 규칙은 여전히 /guides/ 디렉터리를 허용하지 않습니다. 이 페이지에는 준비 과정에서 남은 NOINDEX 지시문도 포함되어 있습니다.
- 의도한 상태를 적어보세요. 이 가이드는 공개되어야 하며 색인 생성이 가능해야 합니다. 아직 완료되지 않은 다른 가이드는 보호가 필요할 수 있습니다.
- 정확한 경로를 확인하세요. 관련 로봇 규칙이 이 URL과 일치하는지 확인하세요. 페이지의 응답 헤더와 HTML에서 noindex를 독립적으로 확인하세요.
- 범위 수정을 수행합니다. 의도한 공개 콘텐츠에 맞게 규칙을 조정하고 원치 않는 noindex 지시문을 제거하세요. 하나의 가이드를 수정하기 위해 완료되지 않은 모든 페이지를 광범위하게 노출하지 마십시오.
- 배포 후 다시 테스트하십시오. 최종 URL이 실제 가이드를 반환하는지, 의도한 크롤러가 이에 액세스할 수 있는지, 헤더와 HTML이 모두 새로운 인덱싱을 반영하는지 확인하세요. 지시.
- Google 증거로 후속 조치를 취하세요. Search Console 속성에서 URL을 검사하고 라이브 테스트를 실행하세요. 페이지가 적합한 경우 색인 생성을 요청할 수 있습니다. 변경 사항을 기록하고 기한을 기약하지 않고 다시 확인하세요.
진단은 "Google에 더 많은 키워드가 필요하다"가 아니라 두 개의 독립적인 장애물입니다. robots 블록만 제거하면 noindex가 그대로 유지됩니다. NOINDEX만 제거하면 Google에서 페이지를 가져올 수 없습니다. 두 가지 수정 사항을 모두 수정한 후에도 성공적인 테스트가 Google의 색인 생성을 보장하지는 않습니다.
요청이 실제로 Google
에서 왔는지 확인하세요.누구나 사용자 에이전트 헤더에 Google봇이라고 주장하는 요청을 보낼 수 있습니다. 의심���러운 트래픽이 사이트에 과부하를 일으키고 있다면 크롤러별 방화벽 규칙을 만들기 전에 출처를 확인하세요.
Google의 요청 확인 지침을 따르세요. 수동 확인을 위해 신뢰할 수 있는 로그에서 소스 IP를 가져와 역방향 DNS 조회를 수행하고 해당 크롤러 카테고리에 대해 문서화된 도메인에 대해 결과 호스트 이름을 확인한 후 해결합니다. 전달 결과는 원래 IP와 일치해야 합니다. 단지 'google'이라는 이름만으로는 부족합니다.
자동 확인을 위해 관련 크롤러 또는 가져오기 카테고리에 대해 Google의 게시된 범위와 주소를 일치시킵니다. 모든 Google 호스팅 트래픽을 Google봇으로 취급하지 마세요. 사이트가 프록시 뒤에 있는 경우 조치를 취하기 전에 어떤 로그 필드가 확인된 클라이언트 주소를 나타내는지 인프라 소유자에게 문의하세요.
Search Console을 사용하여 다음 조치 결정
Google의 URL 검사 문서는 Google의 색인 정보와 실제 테스트를 구��합니다. 색인화된 보고서는 Google가 알고 있는 버전을 반영합니다. 실시간 테스트는 현재 페이지의 잠재적 접근성 및 색인 생성 가능성을 확인합니다. 성공적인 라이브 테스트나 인덱싱 요청 모두 포함을 보장하지 않습니다.
자신의 자산에 액세스할 수 있는 계정을 사용하세요. 가능한 경우 검사한 URL, 마지막 크롤링 정보, 색인 상태 및 표준 정보를 비교하세요. 새로운 서버 수정 사항은 이전에 색인화된 정보와 공존할 수 있습니다. 수정이 실패하기 전의 날짜를 기록해 두십시오.
하나의 증거 기반 작업으로 마무리합니다. URL이 제대로 연결되지 않은 경우 검색 기능을 향상하고, 요청이 실패한 경우 액세스를 복구하고, 의도하지 않은 색인 제한을 제거하고, Google이 페이지를 크롤링했지만 제외한 경우 콘텐츠 및 중복을 조사합니다. URL, 관찰, 변경 및 후속 조치에 대한 간단한 기록을 유지하십시오. 그러면 "Google이 우리를 찾지 못했습니다"라는 문제가 실제로 조사할 수 있는 문제로 변합니다.
