아이프레임 속 내용의 수집 여부

화면 표시와 수집 여부의 판단 기준

아이프레임을 사용하는 화면에는 방문자가 접속한 바깥 페이지와 그 안에서 불러오는 문서가 있습니다. 마케팅 담당자가 바깥 페이지 주소만 개발 담당에게 전달하면, 삽입 문서에 적용된 제한이 조사 대상에서 빠질 수 있습니다. 먼저 어떤 문서를 불러오는지 특정하고, 그 문서를 가져올 수 있는 상태인지와 색인 생성을 허용하는 상태인지를 각각 판단해야 합니다.

구글의 서치 콘솔 도움말은 페이지를 가져올 수 있어도 다른 이유로 색인이 생성되지 않을 수 있다고 설명합니다. 따라서 문서 가져오기에 성공했다는 결과를 색인 완료로 기록해서는 안 됩니다. 운영자는 가져오기 결과, 색인 지시, 실제 색인 상태에 관한 자료를 서로 다른 항목으로 관리해야 합니다.

접근 제한과 색인 지시의 차이

접근 차단과 색인 금지는 같은 처리 상태가 아닙니다. 구글은 robots.txt로 차단된 페이지에서는 NOINDEX를 읽고 따를 수 없어, 서치 콘솔의 색인 생성 허용 여부가 ‘예’로 표시될 수 있다고 설명합니다. 이때 ‘예’라는 표시만으로 문서가 정상적으로 수집되거나 색인 금지 설정이 해제됐다고 판단하면 안 됩니다.

표의 조건은 아이프레임 전체에 대한 일괄 판정표가 아닙니다. 개발 담당자는 해당 문서에 실제로 적용된 조건을 제시하고, 운영자는 그 조건으로 설명할 수 있는 범위까지만 결론을 작성해야 합니다. 바깥 페이지에서 얻은 결과를 삽입 문서의 결과 칸에 대신 기재하지 않습니다.

삽입 상태에 적용되는 색인 조건

NOINDEX와 indexifembedded를 함께 사용하는 조건은 문서가 삽입된 상태인지에 따라 판단해야 합니다. 구글 도움말의 설명을 ‘NOINDEX가 있어도 언제나 색인된다’는 의미로 확대하면 독립 문서와 삽입 문서의 처리 차이를 놓치게 됩니다. 운영자는 두 지시의 존재 여부뿐 아니라 어떤 문서가 어느 페이지에 삽입됐는지까지 연결해 기록해야 합니다.

이 조건은 구글의 색인 생성에 관한 설명입니다. 이를 다른 AI 검색 서비스의 수집 방식이나 답변 인용 여부에 그대로 적용할 근거는 없습니다. 특정 서비스에 관한 질문을 받았다면 구글에서 판단한 항목과 그 서비스에서 아직 조사하지 않은 항목을 따로 표시해야 합니다.

삽입 문서부터 시작하는 조사 순서

조사는 삽입 문서 주소 파악, 접근 제한 확인, 삽입 문서의 색인 조건 확인 순서로 진행합니다. 마케팅 담당자는 내용이 표시되는 페이지를 전달하고, 개발 담당자는 그 화면이 실제로 불러오는 문서를 특정해야 합니다. 주소를 추정해서 기재하면 다른 문서의 설정을 조사할 수 있으므로 개발 담당의 응답을 받은 뒤 다음 단계로 진행합니다.

1. 바깥 페이지와 아이프레임이 불러오는 문서의 주소를 각각 기록합니다. 개발 담당에게 두 문서의 연결 관계와 삽입 문서의 관리 주체를 요청합니다.
2. 삽입 문서에 적용된 접근 제한 자료를 받습니다. robots.txt 차단 여부와 문서 요청 결과를 별도 항목으로 기재하고, 결과를 얻지 못한 이유도 기록합니다.
3. 삽입 문서의 색인 지시를 조사합니다. NOINDEX와 indexifembedded가 실제로 함께 사용되는지 개발 담당에게 요청하고, 문서의 설정과 서치 콘솔 결과를 대조합니다.

담당자가 전달하는 자료에는 대상 문서와 조사 시점을 함께 기재하도록 요청합니다. 화면 캡처만 받으면 어느 문서의 조건을 조사했는지 특정하기 어렵습니다. 필요한 설정 자료를 받지 못했다면 다음 항목을 추정으로 채우지 말고 자료가 없는 상태를 그대로 남깁니다.

개발 담당에게 요청할 자료

자료 요청은 바깥 페이지와 삽입 문서를 따로 지정해야 합니다. 개발 담당자가 ‘페이지에 문제없음’이라고 답하더라도 어느 문서를 어떤 항목으로 조사했는지 알 수 없다면 판단 근거로 쓰기 어렵습니다. 마케팅 담당자는 아래 항목에 맞춰 응답을 받아 업무 기록에 옮깁니다.

외부에서 관리하는 문서는 내부 개발 담당이 설정 자료를 확보하지 못할 수 있습니다. 이 경우 내부 담당자는 문서 주소와 관리 주체를 전달하고, 운영자는 관리 주체에게 필요한 항목을 요청합니다. 답변을 받기 전에는 설정을 변경할 수 있는 사람과 현재 상태를 설명할 수 있는 사람을 같은 담당자로 간주하지 않습니다.

구글은 실시간 테스트가 모든 조건을 감지하거나 색인 성공을 확실하게 예측하지는 못한다고 안내합니다. 운영자는 실시간 결과를 해당 시점의 조사 자료로 보관하고, 그 결과에 포함되지 않은 항목까지 완료로 처리하지 않아야 합니다. 후속 자료가 필요하면 미해결 항목에 필요한 자료의 종류를 기재합니다.

근거와 미판정 항목의 기록

조사 기록에는 결론뿐 아니라 그 결론이 성립하는 대상을 명시해야 합니다. ‘아이프레임 수집 가능’처럼 넓은 문구를 쓰면 특정 문서의 설정 결과가 사이트 전체에 대한 판단으로 전달될 수 있습니다. 운영자는 문서별로 확인된 조건, 그 조건에서 내릴 수 있는 판단, 아직 자료가 없는 항목을 나눠 작성합니다.

확인된 조건에는 개발 담당이 전달한 설정과 해당 문서의 검사 결과를 기재합니다. 판단 칸에는 접근 단계의 결과인지 색인 조건에 관한 결과인지 명시하고, 수집 여부를 확정할 자료가 없다면 미판정으로 남깁니다. 단순히 ‘문제없음’이라고 작성하는 대신 어떤 항목에 제한이 발견되지 않았는지 범위를 좁혀 표현합니다.

자료가 서로 맞지 않을 때는 더 유리한 결과를 선택하지 않습니다. 문서 주소, 조사 시점, 설정 변경 여부를 먼저 대조하고 차이가 발생한 이유를 개발 담당에게 요청합니다. 원인을 특정하지 못하면 두 자료를 모두 보관하고, 해석이 필요한 항목을 미해결로 기록합니다.

수정 요청과 판단 완료의 분리

수정 요청을 전달했다는 사실과 조사 항목이 해결됐다는 사실은 별개로 기록해야 합니다. 개발 담당이 작업 완료를 알리면 운영자는 변경 대상 문서와 변경한 설정을 받아 기존 기록에 추가합니다. 작업 내용만으로 결과를 추정하지 말고, 요청했던 자료가 다시 확보됐는지에 따라 해당 항목의 상태를 변경합니다.

팀 보고에서는 문서 단위의 결과와 사이트 전체의 결과를 혼용하지 않아야 합니다. 일부 삽입 문서를 조사했는데 모든 아이프레임의 상태가 같은 것처럼 보고하면 이후 작업의 대상이 잘못 정해질 수 있습니다. 보고 담당자는 조사한 문서 목록을 명시하고, 목록에 없는 문서는 결론의 적용 대상에서 제외합니다.

기록을 다른 팀에 전달할 때는 기술 지시의 이름과 업무상 판단을 따로 작성합니다. 설정 이름만 전달하면 마케팅 담당자가 무엇을 완료로 처리해야 하는지 알기 어렵습니다. 반대로 업무상 결론만 전달하면 개발 담당이 어떤 조건을 근거로 판단했는지 재현하기 어려우므로 두 정보를 함께 보관합니다.

이어서 읽을 주제

병원 FAQ 페이지는 질문과 답변을 어떤 문서에 담고 관리할지 정하는 문제로 이어 읽을 수 있습니다. 병원 광고 연결페이지는 광고가 안내하는 목적지와 방문자가 받는 설명의 관계를 정리하는 데 필요한 주제입니다.