2019년 7월 1일 월요일
로봇 제외 프로토콜(REP)은 25년 동안 웹에서 가장 기본적이며 중요한 구성요소였습니다. 웹사이트 소유자는 REP를 사용해 웹 크롤러와 같은 자동화된 클라이언트가 사이트에 액세스하는 것을 부분적이거나 완전히 방지합니다.
1994년, 크롤러로 인해 사이트에 과부하가 발생하자 웹마스터 마트진 코스터는 최초의 표준을 마련했습니다. 여기에 다른 웹마스터들의 의견이 더해지면서 REP가 탄생했으며, 검색엔진에서 채택되어 웹사이트 소유자가 서버 리소스를 더 쉽게 관리하도록 도움을 주었습니다.
하지만 REP는 공식 인터넷 표준으로 전환되지 않았습니다. 다시 말해 지난 몇 년 동안 개발자들은 저마다 이 프로토콜을 조금씩 다르게 해석해 온 것입니다. REP는 처음 만들어진 이래 극단적인 최신 사례를 다루도록 업데이트되지 않았습니다. 사실상의 표준이 모호하게 적용되는 바람에 규칙을 올바르게 작성하기가 어려웠고, 이로 인해 웹사이트 소유자들은 어려운 문제에 직면했습니다.
Google에서는 웹사이트 소유자와 개발자가 크롤러를 어떻게 제어해야 할까를 걱정하는 대신, 인터넷에서 놀라운 경험을 만들 수 있게 돕고 싶었습니다. 그리하여 Google은 프로토콜의 원래 작성자, 웹마스터, 다른 검색엔진과 힘을 합쳐 최신 웹의 REP 사용 방식을 문서화하여 IETF에 제출했습니다.
제안된 REP 초안에는 Googlebot과 기타 주요 크롤러에서 사용하는 robots.txt 규칙을 사용한 20년 이상의 실제 경험과 REP를 사용하는 약 5억 개의 웹사이트가 반영되어 있습니다. 이러한 세분화된 제어 기능을 통해 게시자는 사이트에서 크롤링하고 관심 있는 사용자에게 표시할 내용을 결정할 수 있습니다. 1994년에 만든 규칙은 변경되지 않지만 대신 robots.txt 파싱 및 일치에 대해 정의되지 않은 모든 시나리오를 정의하고 최신 웹에 맞게 확장합니다. 주목할 사항:
- 모든 URI 기반 전송 프로토콜이 robots.txt를 사용할 수 있게 됩니다. 예를 들어 이러한 프로토콜이 더 이상 HTTP에 한정되지 않으며 FTP 또는 CoAP에도 사용할 수 있게 됩니다.
- 개발자는 robots.txt에서 적어도 첫 500키비바이트를 파싱해야 합니다. 최대 파일 크기를 정의하면 연결이 너무 오랫동안 열려 있지 않게 할 수 있기 때문에 불필요한 서버 부담이 줄어듭니다.
- 최대 캐싱 시간이 이제 24시간 또는 캐시 지시어 값(사용 가능한 경우)으로 설정되기 때문에 웹사이트 소유자는 언제든지 robots.txt를 유연하게 업데이트할 수 있으며, 크롤러의 robots.txt 요청으로 인해 웹사이트에 과부하가 발생하지 않습니다. 예를 들어 HTTP의 Cache-Control 헤더를 캐싱 시간을 결정하는 데 사용할 수 있습니다.
- 이제 사양에서 프로비저닝을 제공합니다. 즉, 서버 문제로 인해 이전에 액세스 가능했던 robots.txt에 액세스할 수 없게 되면 상당히 긴 기간 동안 알려져 있는 허용 금지 페이지가 크롤링되지 않습니다.
또한 개발자가 라인을 파싱할 때 중요한 robots.txt 구문을 더 잘 정의할 수 있도록 인터넷 초안의 증강된 Backus-Naur 양식을 업데이트했습니다.
RFC는 Requests for Comments('의견을 말해주세요')의 약자인데, 우리는 진심입니다. 인터넷의 기본 구성 요소에 관심이 있는 개발자 여러분의 의견을 받기 위해 IETF에 초안을 업로드했습니다. 우리 Search Console팀은 웹 제작자가 Googlebot에 제공하고자 하는 정보의 양, 그리고 Google 검색에 표시할 수 있는 정보에 관해 Google에 알릴 수 있는 제어 기능을 '제대로' 만들고 싶습니다.
오프라인과 온라인 모두에서 트위터나 웹마스터 커뮤니티를 통해 의견을 남기거나, 궁금한 점을 질문해 주세요. 인사만 건네셔도 좋습니다.