AI 크롤러 이름이 바뀌었을 때 robots.txt 고치기

규칙용 식별자 변경의 판단 기준

서비스의 표시 이름이 달라졌다는 소식만으로 수정 대상을 정하지 않습니다. 운영자는 공식 변경 안내에서 robots.txt에 쓰는 식별자도 변경됐는지 먼저 확인합니다. 새 이름을 소개하는 문장과 접근 규칙에 사용할 문자열을 안내하는 문장은 서로 다른 자료일 수 있습니다. 규칙용 식별자를 명시한 근거가 없다면 임의로 새 이름을 입력하지 않고 해당 안내를 확보합니다.

구글 문서는 규칙 묶음이 적용될 크롤러를 User-agent 행으로 지정한다고 설명합니다. 운영 업무에서는 이 행을 규칙의 대상 크롤러를 지정하는 행으로 이해하면 됩니다. 따라서 이번 수정의 출발점은 새 서비스를 허용할지 결정하는 일이 아니라, 기존 대상에 적용하던 정책을 새 식별자에 옮길 수 있는지 판단하는 일입니다.

공식 안내는 식별자 변경의 근거로 사용하고, 사이트의 기존 접근 정책은 내부 승인 자료에서 찾습니다. 두 자료가 모두 있어야 담당자가 이름 수정과 정책 변경을 따로 처리할 수 있습니다. 안내가 다른 크롤러의 추가를 설명한다면 이름만 교체하는 요청으로 진행하지 않습니다.

기존 대상 행과 경로 규칙의 연결

대상 행을 찾은 뒤에는 그 행과 연결된 경로 규칙을 함께 추출합니다. User-agent라는 글자만 검색해 교체할 위치를 정하면, 어느 파일과 어느 규칙 묶음을 수정하는지 요청서에서 빠질 수 있습니다. 담당자는 현재 게시된 내용에서 대상 행과 이어지는 Allow·Disallow 행을 함께 가져와 수정 전 자료로 보관합니다.

경로 규칙에는 경로 문자열과 허용·차단 지시를 각각 기재합니다. 이름을 옮기는 과정에서 경로를 넓히거나 일부 제한을 삭제하는 요청이 섞였다면 별도 정책 변경으로 분리합니다. 기존 정책의 이유를 찾을 수 없는 경로는 이름 수정에 편승해 정리하지 않고, 정책 담당자에게 유지 여부를 묻습니다.

구글 문서는 robots.txt가 게시된 프로토콜·호스트·포트의 범위에만 적용된다고 설명합니다. 운영자는 수정할 파일이 실제 대상 사이트의 파일인지 식별한 뒤 작업을 요청합니다. 별도로 운영하는 파일이 있다면 파일별로 기존 설정을 수집하며, 한 파일의 수정 결과를 나머지 파일에도 적용됐다고 기록하지 않습니다.

수정 요청에 필요한 자료와 순서

마케팅 담당자는 공식 안내, 현재 게시된 파일의 내용, 기존 접근 정책을 설명하는 자료를 준비합니다. 기술 담당자는 이 자료를 받아 수정할 대상 행과 유지할 경로 규칙을 명시합니다. 요청서에는 이름 전환만 처리하는지, 별도 승인을 받은 정책 변경도 함께 처리하는지 기재합니다.

1. 공식 변경 안내에서 새 규칙용 식별자와 전환 조건을 추출하고, 근거 문서의 제목과 확인 날짜를 남깁니다.
2. 현재 파일의 대상 행과 연결된 경로 규칙을 대조하고, 이름 수정에 포함할 행을 지정합니다.
3. 수정 전후 내용을 준비해 경로별 허용·차단 의도가 유지되는지 정책 담당자의 승인을 받습니다.
4. 기술 담당자가 수정안을 게시한 뒤 파일 접근과 규칙 해석 결과를 각각 전달합니다.

요청서의 수정 전후 자료에는 변경하지 않을 행도 판단에 필요한 범위만큼 포함합니다. 담당자가 새 식별자만 전달받으면 연결할 경로 규칙을 다시 추정해야 하기 때문입니다. 옛 식별자의 처리 근거가 없을 때는 그 항목을 미결정으로 표시하고, 삭제나 병기를 완료 조건에 임의로 넣지 않습니다.

게시된 파일의 접근과 해석 결과

작업 완료는 편집한 파일을 저장했다는 보고만으로 판단하지 않습니다. 구글 문서는 업로드 후 파일의 공개 접근과 규칙 해석 가능 여부를 시험하도록 안내합니다. 운영자는 시크릿 브라우징 창이나 이에 상응하는 창에서 게시된 robots.txt의 내용을 읽을 수 있는지 확인하고, 승인한 수정안과 대조합니다.

구글 문서는 이미 접근 가능한 파일을 대상으로 서치 콘솔의 robots.txt 보고서를 사용할 수 있다고 설명합니다. 개발자가 로컬에서 규칙을 시험할 수 있는 구글의 오픈소스 robots.txt 라이브러리도 안내합니다. 이 도구의 결과를 다른 AI 플랫폼의 해석 결과로 간주하지 않고, 대상 플랫폼에 관한 판단은 해당 플랫폼의 공식 설명을 근거로 요청합니다.

완료 보고에는 게시된 내용이 승인안과 일치하는지, 어떤 근거와 방법으로 해석을 판단했는지를 남깁니다. 대상 플랫폼의 해석을 판단할 자료가 부족하다면 파일 게시 완료와 해석 미확정을 따로 기재합니다. 이름 수정과 파일 게시만으로 실제 수집·색인·검색 노출·인용까지 완료됐다고 보고하지 않습니다.

옛 식별자의 삭제와 병기 조건

옛 식별자를 삭제할지 새 식별자와 함께 기재할지는 공식 전환 안내가 확보된 경우에만 결정합니다. 새 이름이 발표됐다는 사실만으로 옛 이름의 사용 종료를 추정하지 않습니다. 반대로 두 이름을 모두 남기는 방법이 언제나 안전하다고 전제하지도 않습니다.

운영자는 안내에서 옛 식별자의 처리 방법을 명시한 문장과 그 조건을 추출합니다. 조건이 있다면 현재 사이트의 수정 요청이 그 조건에 해당하는지 기재합니다. 안내가 새 식별자만 제시하고 옛 식별자의 처리에 관해서는 설명하지 않는다면, 그 공백을 담당자의 추측으로 채우지 않습니다.

병기를 승인받은 경우에는 각 이름에 연결할 경로 규칙을 수정안에 명시합니다. 기술 담당자가 복사 과정에서 일부 경로를 누락하거나 두 이름에 서로 다른 지시를 입력하지 않도록 전후 자료를 준비합니다. 이름이 비슷하다는 이유로 별도 크롤러의 규칙까지 복사하는 작업은 이번 전환 요청에서 제외합니다.

전체 치환과 정책 변경의 혼입

자동 치환을 사용하더라도 변경 대상으로 지정한 규칙 행에 한정합니다. 같은 문자열이 설명 문장이나 별도 설정 자료에도 들어 있을 수 있으므로, 검색 결과 전체를 수정 범위로 삼지 않습니다. 치환 후에는 실제로 달라진 행을 추출해 승인안에 없는 변경이 포함됐는지 가립니다.

새 이름으로 통일하는 과정에서 오래된 경로를 정리하자는 요청이 함께 들어올 수 있습니다. 경로 정리가 필요하다면 사유와 승인 대상을 별도 항목으로 작성합니다. 식별자 전환의 완료 여부와 경로 정책 변경의 승인 여부를 한 항목으로 묶으면, 문제가 발생했을 때 어떤 수정이 원인인지 판단하기 어려워집니다.

다른 크롤러의 대상 행이나 공통 규칙까지 달라졌다면 의도한 수정인지 담당자가 설명하도록 요청합니다. 설명이 없는 변경은 게시 승인 범위에서 제외합니다. 기술 담당자는 이름 전환에 필요한 수정과 그 밖의 정비를 나누어 제출하고, 운영자는 승인한 범위만 완료 처리합니다.

게시 내용을 다시 생성하는 설정의 관리

게시된 파일을 수정한 뒤 별도 관리 설정에서 이전 내용이 다시 생성되지 않는지도 판단해야 합니다. 운영 환경에 따라 파일을 직접 편집하거나 관리 설정을 통해 내용을 만들 수 있으므로, 기술 담당자에게 실제 수정 내용이 유지되는 위치를 설명하도록 요청합니다. 이는 특정 플랫폼의 기능을 전제하는 절차가 아니라 변경 내용을 관리하기 위한 업무 기준입니다.

배포 자료나 관리 설정에 옛 식별자가 남아 있다면 다음 작업에서 이전 설정이 재사용될 가능성을 담당자에게 묻습니다. 현재 게시본만 수정했는지, 내용을 생성하는 설정까지 수정했는지를 완료 보고에 기재합니다. 수정할 수 없는 자료는 삭제하는 대신 사용 여부와 후속 조치 담당자를 기록합니다.

이어서 읽을 주제

병원 GEO 실행 순서는 업종별 운영 자료와 담당 업무를 어떤 순서로 준비하는지 이해하기 위해 이어 읽을 주제입니다. 기술 설정의 변경 요청을 전체 운영 절차 안에서 언제 처리할지 정하려는 담당자에게 연결됩니다.