웹사이트 준비노트https://www.worksdesign.co.kr홈페이지·쇼핑몰을 만들기 전에 챙길 것을 순서대로Tue, 27 Oct 2026 05:52:00 +0900쇼핑몰 결제 화면에서 피해야 할 눈속임 설계https://www.worksdesign.co.kr/guide/checkout-dark-patterns/https://www.worksdesign.co.kr/guide/checkout-dark-patterns/Tue, 27 Oct 2026 05:52:00 +0900<section id="section-1"><h2>결제 화면과 연결된 구매 과정의 판단 기준</h2><figure><img alt="결제 화면을 설명하는 개념 도해" height="800" src="https://www.worksdesign.co.kr/media/checkout-dark-patterns-1.webp" width="800"/><figcaption>결제 화면 · 실제 수치나 관리 화면이 아닌 개념 도해입니다.</figcaption></figure><p>쇼핑몰 결제 화면은 추가 상품을 미리 선택하거나 사업자에게 유리한 선택만 두드러지게 만들고, 거절한 선택을 반복 요구하지 않도록 설계해야 합니다. 구매 전 가격 안내와 정기결제 동의, 취소·탈퇴 경로까지 함께 확인해야 합니다. 운영자는 결제 버튼이 있는 화면뿐 아니라 고객이 구매를 시작하고 종료하는 과정까지 제작 담당자에게 시연해 달라고 요청합니다.</p><p>공정거래위원회의 「전자상거래 등에서의 소비자보호 지침 개정」 보도자료는 숨은갱신, 순차공개 가격책정, 특정옵션의 사전선택, 잘못된 계층구조, 취소·탈퇴 등의 방해, 반복간섭을 온라인 다크패턴 유형으로 설명합니다. 운영자는 이 유형을 화면과 동작을 가리는 질문으로 풀어 활용할 수 있습니다. 아래 표는 개별 화면의 위법 여부를 판정하는 표가 아니며, 제작 담당자에게 수정 범위를 전달하기 위한 실무 항목입니다.</p><table><thead><tr><th>공식 문서의 유형</th><th>운영자가 확인할 화면·동작</th><th>제작 담당자에게 물을 말</th></tr></thead><tbody><tr><td>순차공개 가격책정·숨은갱신</td><td>검색 결과의 가격 안내와 정기결제 조건 변경 과정</td><td>구매에 필요한 총비용과 증액·유료 전환 동의를 어디에서 안내하고 받습니까?</td></tr><tr><td>특정옵션의 사전선택</td><td>다른 상품을 추가하는 항목의 첫 상태</td><td>고객이 선택하기 전에 추가 상품이 선택되어 있습니까?</td></tr><tr><td>잘못된 계층구조</td><td>선택 버튼의 크기·모양·색깔</td><td>사업자에게 유리한 선택만 현저하게 강조했습니까?</td></tr><tr><td>반복간섭</td><td>거절한 뒤 다시 나타나는 팝업과 제안</td><td>고객이 거절한 선택을 다시 변경하도록 요구합니까?</td></tr><tr><td>취소·탈퇴 등의 방해</td><td>취소·탈퇴의 시작부터 완료까지</td><td>완료에 필요하지 않은 절차가 진행을 어렵게 합니까?</td></tr></tbody></table><p>같은 상품이라도 처음 방문한 고객과 기존 회원에게 나타나는 안내가 다를 수 있습니다. 운영자는 실제 판매 방식에 해당하는 이용 상태를 정하고, 각 상태에서 나타나는 화면을 준비하도록 요청합니다. 정지된 화면 이미지에 드러나지 않는 동작은 직접 진행하면서 판단합니다.</p></section><section id="section-2"><h2>일부 가격 안내와 정기결제 동의의 범위</h2><p>공정거래위원회는 검색 결과 화면에서 구매에 필요한 총비용 대신 일부 금액만 표시하는 행위를 순차공개 가격책정으로 설명합니다. 따라서 결제 화면의 최종 합계가 맞더라도 구매 전 가격 안내를 점검 범위에서 제외하지 않습니다. 운영자는 검색 결과에 사용하는 상품 가격 자료와 결제 단계의 비용 항목을 연결해 대조하고, 차이가 발생하는 이유를 제작 담당자에게 설명하도록 요청합니다.</p><p>공정거래위원회는 정기결제 대금의 증액이나 무료 공급 뒤 유료 전환에 소비자의 사전 동의가 필요하다고 설명합니다. 정기 배송 상품이나 유료 이용권을 판매한다면 운영자는 어떤 조건이 변경되는지 먼저 정리합니다. 이어서 변경 안내 문구와 동의를 받는 화면, 고객이 응답한 뒤 처리되는 동작을 함께 요청합니다. 일반 구매 동의와 조건 변경 동의를 같은 것으로 취급하지 않도록 요구사항을 명확하게 씁니다.</p></section><section id="section-3"><h2>구매 흐름에 따른 실행 순서</h2><p>실행 순서는 가격·결제 조건 안내, 추가 상품과 선택 버튼, 반복 요구와 취소·탈퇴 경로로 정합니다. 운영자는 정상적으로 구매를 완료하는 과정과 중간에 선택을 거절하거나 종료하는 과정을 각각 진행합니다. 제작 담당자는 각 동작의 결과를 보여 주고, 운영자는 의도한 판매 조건과 다른 부분을 수정 요청에 남깁니다.</p><table><thead><tr><th>점검할 구매 단계</th><th>진행할 작업</th><th>확인 결과와 수정 요청</th></tr></thead><tbody><tr><td><label><input data-check="S47-A0002-p2-process-0" type="checkbox"/>구매 전 가격·결제 조건 안내</label></td><td>노출 가격과 결제 비용 항목을 대조하고 정기결제 변경 동의 과정을 진행합니다.</td><td>가격 차이의 이유와 누락된 안내, 동의를 받는 시점을 정리합니다.</td></tr><tr><td><label><input data-check="S47-A0002-p2-process-1" type="checkbox"/>추가 상품 선택</label></td><td>고객이 아무것도 선택하지 않은 상태에서 구매를 시작합니다.</td><td>자동으로 포함된 다른 상품과 초기 선택 상태의 수정 내용을 남깁니다.</td></tr><tr><td><label><input data-check="S47-A0002-p2-process-2" type="checkbox"/>선택 버튼과 거절 이후</label></td><td>수락·거절 항목을 비교하고 거절한 뒤 구매를 계속합니다.</td><td>편향된 강조와 재등장하는 요구의 발생 조건을 전달합니다.</td></tr><tr><td><label><input data-check="S47-A0002-p2-process-3" type="checkbox"/>취소·탈퇴 진행</label></td><td>시작 화면에서 완료 결과까지 직접 이동합니다.</td><td>진행을 막는 단계와 제거하거나 고칠 동작을 요청합니다.</td></tr></tbody></table><p>수정 요청에는 화면 이름과 고객이 누른 항목, 실제로 발생한 동작, 원하는 처리 결과를 함께 씁니다. 화면 이미지에는 문제가 발생한 위치를 표시하고, 연속 동작이 필요한 문제에는 진행 순서를 추가합니다. 표현을 단순히 순하게 고쳐 달라고 요청하지 말고 어느 선택과 어떤 동작을 변경할지 지정합니다.</p></section><section id="section-4"><h2>운영자와 제작 담당자의 준비 자료</h2><p>운영자는 상품별 판매 가격, 필수 비용과 선택 비용, 추가 판매 상품, 정기결제 조건을 먼저 정리합니다. 취소와 탈퇴를 처리하는 실제 업무 순서도 함께 준비합니다. 판매 조건이 확정되지 않은 항목은 임시 문구로 완성 처리하지 않고, 누가 조건을 결정할지 정해 제작 담당자에게 전달합니다.</p><p>제작 담당자에게는 결제 화면 이미지와 함께 선택 항목의 초기 상태, 버튼을 누른 뒤의 이동, 팝업이 나타나는 조건을 요청합니다. 외부 결제 기능이나 쇼핑몰의 공통 설정을 사용하는 부분은 운영자가 직접 변경할 수 있는 범위를 따로 설명하도록 합니다. 직접 수정할 수 없는 항목에는 설정 변경 가능 여부와 서비스 제공자에게 요청할 내용을 정리합니다.</p><p>작업 완료 기준은 화면 파일을 전달받는 시점과 분리해 정합니다. 수정된 환경에서 운영자가 같은 순서로 다시 진행하고, 요청한 동작이 실제로 달라졌는지 대조합니다. 일부 수정이 남았다면 완료 항목과 미완료 항목을 나누어 인수 자료에 포함합니다.</p></section><section id="section-5"><h2>선택의 초기 상태와 시각적 강조의 차이</h2><figure><img alt="선택 조건 확인을 설명하는 개념 도해" height="800" loading="lazy" src="https://www.worksdesign.co.kr/media/checkout-dark-patterns-2.webp" width="800"/><figcaption>선택 조건 확인 · 실제 수치나 관리 화면이 아닌 개념 도해입니다.</figcaption></figure><p>추가 상품이 이미 선택된 문제와 특정 버튼이 지나치게 강조된 문제는 수정 대상이 다릅니다. 전자는 고객이 행동하기 전의 선택 상태를, 후자는 선택 항목 사이의 표현 차이를 다룹니다. 버튼 색을 변경했더라도 다른 상품이 자동으로 포함되는 동작이 남아 있다면 초기 상태를 별도로 수정해야 합니다.</p><p>공정거래위원회가 설명하는 특정옵션의 사전선택은 상품 구매 과정에서 다른 상품의 구매 여부를 미리 선택하는 행위입니다. 운영자는 필수 구매 구성과 별도로 판매하는 상품을 먼저 가려 제작 담당자에게 전달합니다. 선택 항목이라는 이름을 달았더라도 고객이 직접 선택하지 않은 상품이 결제 합계에 포함된다면 그 발생 과정을 수정 요청에 담습니다.</p><p>잘못된 계층구조에 관한 공식 설명은 크기·모양·색깔의 현저한 차이로 사업자에게 유리한 항목을 유인하는 방식에 관한 내용입니다. 모든 버튼의 외형을 똑같이 만들어야 한다는 결론으로 확대하지 않습니다. 운영자는 고객에게 제시하는 선택의 의미를 먼저 정하고, 제작 담당자에게 각 항목의 표현 차이를 설명하도록 요청합니다.</p></section><section id="section-6"><h2>거절 뒤 요구와 취소 방해의 수정 단위</h2><p>반복 요구를 고칠 때는 팝업 문구보다 다시 나타나는 조건을 먼저 지정합니다. 고객이 추가 구매를 거절한 뒤 다음 화면에서 같은 선택을 다시 요구한다면, 개별 창을 닫을 수 있는지만으로 작업을 끝내지 않습니다. 제작 담당자에게 거절 이후 이어지는 동작을 전달하고 재요구가 발생하는 설정을 수정하도록 요청합니다.</p><p>취소·탈퇴 과정에서는 다음 단계가 있다는 사실과 완료되었다는 사실을 혼동하지 않아야 합니다. 운영자는 접수 안내를 받은 상태인지 실제 처리가 끝난 상태인지 가리고, 각 상태에서 고객에게 전달할 문구를 정합니다. 운영상 필요한 처리가 있다면 그 이유와 고객이 할 일을 설명하고, 완료에 불필요한 설문이나 구매 제안이 진행을 막는지 따로 시험합니다.</p></section><section id="section-7"><h2>행사 설정 변경 뒤의 재발 방지</h2><p>출시 때 정비한 화면도 행사나 상품 묶음을 추가하는 과정에서 달라질 수 있습니다. 운영자는 할인 행사와 추가 판매 설정을 변경할 때 기존 요구사항을 함께 적용하도록 작업 요청에 포함합니다. 기존 화면을 복사했다면 문구뿐 아니라 선택 상태와 버튼 동작까지 복사되었는지 담당자에게 묻습니다.</p><p>화면을 관리하는 사람이 여러 명이라면 상품 등록 담당자와 행사 담당자가 사용하는 설정도 정리합니다. 특정 화면의 수정으로 끝내지 않고 이후 같은 요소를 만드는 작업에 적용할 작성 규칙을 남깁니다. 규칙에는 허용할 표현과 피할 동작을 구체적으로 쓰고, 새 기능을 추가할 때 이를 다시 적용할 책임자를 정합니다.</p></section><section id="section-8"><h2>자주 묻는 질문</h2><h3>상품 추천 영역도 모두 없애야 합니까?</h3><p>상품 추천을 전부 제거하는 방식으로 요구사항을 정할 필요는 없습니다. 추천 내용을 읽는 행위와 실제 구매를 선택하는 행위를 분리해 설계하도록 요청합니다. 추천 영역에 상품이 표시되었다는 이유로 구매 의사가 처리되지 않도록 동작을 정합니다.</p><h3>쇼핑몰 기본 양식을 쓰면 별도 판단이 필요 없습니까?</h3><p>기본 양식도 운영자가 추가한 상품 구성과 행사 설정에 따라 실제 동작이 달라질 수 있습니다. 양식의 이름이나 공급자의 설명을 완료 근거로 삼지 말고, 현재 판매 환경을 대상으로 인수 절차를 진행합니다. 직접 변경하기 어려운 부분은 지원 요청 내용과 처리 결과를 보관합니다.</p><h3>취소 과정의 고객 설문은 어떻게 처리해야 합니까?</h3><p>설문을 수집하려는 목적과 취소 처리를 분리해 설계하는 방안을 요청할 수 있습니다. 운영자는 답변하지 않은 고객도 절차를 완료하도록 할지 명시하고, 제작 담당자에게 응답하지 않았을 때의 동작을 시연하도록 합니다. 설문이 있다는 이유만으로 개별 화면의 법적 성격을 단정하지 않습니다.</p><h3>테스트 화면에 실제 고객 정보를 넣어야 합니까?</h3><p>선택 버튼과 화면 이동을 시험하기 위해 실제 고객 정보를 기본 자료로 사용할 필요는 없습니다. 운영자는 시험용 계정과 주문 자료를 준비하고 실제 주문 처리와 섞이지 않도록 작업 범위를 정합니다. 개인정보가 포함된 화면을 공유해야 한다면 작업에 필요하지 않은 내용은 제외합니다.</p><h3>화면 수정이 어렵다면 안내문만 추가해도 됩니까?</h3><p>문제를 일으키는 동작이 남아 있다면 안내문 추가를 동작 수정과 같은 완료 항목으로 처리하지 않습니다. 운영자는 임시 안내와 실제 수정 작업을 나누고, 변경이 어려운 기능은 사용을 멈추거나 다른 구매 방식으로 대체할 수 있는지 결정합니다. 법적 판단이 필요한 사안은 화면 자료와 판매 조건을 정리해 적절한 전문가에게 자문을 요청합니다.</p></section>호스팅을 옮길 때 검색에서 끊기지 않게 하는 순서https://www.worksdesign.co.kr/guide/hosting-move-order/https://www.worksdesign.co.kr/guide/hosting-move-order/Tue, 27 Oct 2026 05:52:00 +0900<section id="section-1"><h2>주소를 유지하는 호스팅 이전의 범위</h2><figure><img alt="호스팅 이전을 설명하는 개념 도해" height="800" src="https://www.worksdesign.co.kr/media/hosting-move-order-1.webp" width="800"/><figcaption>호스팅 이전 · 실제 수치나 관리 화면이 아닌 개념 도해입니다.</figcaption></figure><p>방문자에게 보이는 주소를 유지하며 호스팅을 옮길 때는 구글봇 접속 차단 여부와 DNS 설정을 먼저 확인하고, 이전 후 주소 연결과 서버 응답을 점검해 검색 접근 장애를 줄입니다. 정상 응답을 받더라도 검색 노출 유지까지 보장할 수는 없습니다.</p><p>호스팅을 변경했다는 이유로 검색에서 반드시 사라지는 것은 아닙니다. 운영자가 우선 가려야 할 문제는 검색로봇이 새 서버에 도달하는지, 요청한 페이지 내용을 제대로 받는지입니다. 검색결과에 표시되는 상태와 서버에 접속할 수 있는 상태는 각각 판단해야 합니다.</p><p>구글 검색 센터의 호스팅 변경 문서는 사용자에게 표시되는 주소가 달라지지 않는 이전을 대상으로 설명합니다. 작은 회사 운영자는 작업을 맡기기 전에 현재 주소를 유지하는지부터 담당자에게 묻습니다. 도메인이나 페이지 주소도 변경한다면 여기의 순서만 적용하지 말고 주소 변경에 필요한 계획을 별도로 요청합니다.</p></section><section id="section-2"><h2>검사 상태별 의미와 판단 한계</h2><p>검사 결과는 주소 연결, 서버 응답, 검색 처리 가능성을 나누어 읽습니다. 서치 콘솔의 URL 검사 도움말과 구글의 HTTP 상태 코드 문서는 각 결과가 뜻하는 범위와 한계를 설명합니다. 담당자에게 성공 여부만 받기보다 아래처럼 어떤 상태였는지 요구합니다.</p><table><thead><tr><th>검사에서 보이는 상태</th><th>뜻을 풀어 설명한 내용</th><th>판단할 때의 한계</th></tr></thead><tbody><tr><td>DNS 서버가 응답하지 않음</td><td>주소를 서버로 연결하는 과정에서 응답을 받지 못한 상태입니다.</td><td>일시적인 문제일 수 있어 이 결과로 지속 장애를 단정하지 않습니다.</td></tr><tr><td>서버 연결 오류</td><td>서버에 연결하지 못했거나 연결 요청이 거부된 상태입니다.</td><td>표시된 상태에 더해 서버 쪽 원인을 조사해야 합니다.</td></tr><tr><td>정상 HTTP 응답</td><td>서버가 요청을 처리하고 콘텐츠를 전달하는 단계입니다.</td><td>성공 응답이 색인 생성을 보장하지는 않습니다.</td></tr><tr><td>URL을 구글에 등록할 수 있음</td><td>실시간 검사에서 수집과 해석을 막는 감지 가능한 오류가 없는 상태입니다.</td><td>가능한 모든 색인 조건이나 검색결과 표시 여부를 판정하지 않습니다.</td></tr></tbody></table><p>접속 장애가 있는 상태라면 원인을 해결하는 작업이 먼저입니다. 접속이 정상이라면 실제 페이지 내용과 도구의 상세 결과를 다음 판단 자료로 사용합니다. 검색결과에서 페이지가 검색되지 않는다는 이유로 DNS 설정부터 다시 변경하지 않도록, 담당자에게 장애가 발생한 단계를 설명해 달라고 요청합니다.</p></section><section id="section-3"><h2>차단 여부부터 시작하는 이전 준비</h2><p>이전 준비는 구글봇이 새 서버에 접근할 수 있는지부터 시작합니다. 구글 검색 센터는 네트워크 접근 제어 설정이나 서비스 거부 공격 보호 설정이 구글봇의 DNS 또는 호스팅 서버 접근을 차단하지 않는지 확인하도록 안내합니다. 운영자는 호스팅 관리 담당자에게 해당 설정의 상태와 접근 시험 결과를 요청합니다.</p><p>DNS는 홈페이지 주소를 접속할 서버로 연결하는 설정입니다. TTL은 그 연결 설정을 보관하는 시간이며, 구글 검색 센터는 인터넷 서비스 제공자가 이 값에 따라 DNS 설정을 임시 보관한다고 설명합니다. TTL을 미리 낮추면 새 설정이 더 빠르게 전달되는 데 도움이 되므로, 담당자에게 변경 가능 여부와 적용 계획을 함께 받습니다.</p><p>DNS 설정을 변경한 사실과 새 연결 정보가 전달된 상태는 따로 판단합니다. 이전 연결 정보를 임시 보관하는 곳이 있을 수 있으므로, 담당자에게 설정 변경 내역과 실제 연결 시험 결과를 함께 요청합니다. 연결 대상이 예상과 다르면 페이지 내용을 수정하기 전에 현재 적용된 DNS 설정과 보관된 설정의 영향을 조사하도록 요청합니다.</p><table><thead><tr><th>확인 단계</th><th>맡긴 곳에 요구할 확인 내용</th><th>확인받을 결과</th></tr></thead><tbody><tr><td>구글봇 접근 준비</td><td>네트워크 접근 제어와 접속 보호 설정이 검색로봇을 막는지 조사합니다.</td><td>차단 여부와 새 서버 접근 시험 결과를 받습니다.</td></tr><tr><td>DNS와 TTL 준비</td><td>현재 연결 대상과 TTL, 새 서버로 변경할 설정을 정리합니다.</td><td>변경 전후 설정과 적용 순서를 받습니다.</td></tr><tr><td>이전 후 주소 연결</td><td>사용 중인 주소가 새 서버로 연결되는지 검사합니다.</td><td>검사한 주소와 연결 대상, 검사 시점을 받습니다.</td></tr><tr><td>서버 응답과 실시간 검사</td><td>페이지 응답과 URL 검사 도구의 상세 결과를 대조합니다.</td><td>응답 상태, 오류 내용, 후속 조치 항목을 받습니다.</td></tr></tbody></table></section><section id="section-4"><h2>운영자와 기술 담당자의 준비 자료</h2><p>운영자는 첫 화면뿐 아니라 상품 상세, 학원 강좌 안내, 전문 서비스 소개처럼 서로 다른 형태의 페이지 주소를 준비합니다. 기술 담당자는 그 주소를 대상으로 앞에서 정한 기준에 따라 검사합니다. 전체 사이트를 검사한 결과인지 일부 주소만 시험한 결과인지도 결과표에 명시하도록 요청합니다.</p><ol class="dk_checklist"><li><label><input data-check="S47-A0003-p2-handoff-0-0" type="checkbox"/>운영자는 유지할 주소 목록과 DNS를 관리하는 담당자의 연락 수단을 전달합니다.</label></li><li><label><input data-check="S47-A0003-p2-handoff-0-1" type="checkbox"/>기술 담당자는 접근 제한 상태를 조사한 뒤 DNS와 TTL 변경 계획을 설명합니다.</label></li><li><label><input data-check="S47-A0003-p2-handoff-0-2" type="checkbox"/>변경 후에는 주소 연결을 검사하고 서버 응답과 실시간 테스트 결과를 순서대로 제출합니다.</label></li></ol><p>작업 결과를 받을 때는 검사 시점과 해결되지 않은 항목도 함께 받습니다. 오류가 있다면 누가 원인을 조사하고 어떤 자료로 다시 판단할지 정합니다. 운영자가 설정을 직접 다루기 어렵더라도 이 자료를 요구하면 작업 완료 통보와 실제 시험 결과를 따로 판단할 수 있습니다.</p></section><section id="section-5"><h2>주소 연결 오류와 응답 오류의 차이</h2><figure><img alt="이전 단계 확인을 설명하는 개념 도해" height="800" loading="lazy" src="https://www.worksdesign.co.kr/media/hosting-move-order-2.webp" width="800"/><figcaption>이전 단계 확인 · 실제 수치나 관리 화면이 아닌 개념 도해입니다.</figcaption></figure><p>이전 후 문제가 생기면 주소가 연결되는 단계와 서버가 내용을 전달하는 단계를 나누어 원인을 가립니다. 서치 콘솔 도움말에서 알 수 없는 호스트는 DNS가 주소를 해석하지 못한 상태이고, 비공개 IP 제공은 공개 접속에 쓰지 않는 범위의 IP를 반환한 상태입니다. 이런 결과가 나오면 페이지 문구를 수정하기 전에 DNS 담당자에게 연결 설정을 조사하도록 요청합니다.</p><p>서버 연결 오류와 잘못된 서버 응답은 같은 문제가 아닙니다. 구글 도움말은 전자를 연결 실패나 거부로, 후자를 응답이나 헤더가 불완전하거나 해석할 수 없는 상태 등으로 설명합니다. 기술 담당자는 오류 문구를 그대로 보관하고 서버 연결과 응답 처리 중 어느 작업이 필요한지 설명해야 합니다.</p><p>HTTPS 주소에서 인증서 오류가 발생했다면 인증서 상태를 별도로 처리합니다. 구글은 SSL 인증서가 유효하지 않으면 해당 HTTPS 주소를 테스트하지 않는다고 안내합니다. 브라우저에서 다른 주소로 접속한 결과를 대신 제출하지 말고 실제 운영 주소의 시험 결과를 받습니다.</p></section><section id="section-6"><h2>정상 응답과 검색 노출 판단의 차이</h2><p>서버가 정상 응답을 보내도 전달한 내용이 빈 화면이나 오류 안내라면 작업 완료로 처리하지 않습니다. 구글의 HTTP 상태 코드 문서는 성공 응답을 받은 콘텐츠도 빈 페이지나 오류 메시지라면 소프트 오류로 처리될 수 있다고 설명합니다. 운영자는 상품명이나 서비스 설명처럼 해당 페이지에 있어야 할 내용이 전달되는지도 검사 항목에 포함합니다.</p><p>실시간 테스트의 성공과 과거 수집 결과가 다를 때는 검사 시점을 함께 대조합니다. 서치 콘솔 도움말에 따르면 수집 당시에는 서버 오류가 발생했지만 실시간 시험은 성공할 수 있고, 그 반대도 가능합니다. 담당자에게 어느 결과가 최신인지와 같은 문제가 반복되는지를 조사하도록 요청합니다.</p></section><section id="section-7"><h2>소유권 인증 수단의 누락 방지</h2><p>호스팅 이전 준비에서는 서치 콘솔 소유권 인증에 사용하는 파일이나 태그도 별도 항목으로 관리합니다. 구글 검색 센터는 HTML 파일로 인증했다면 새 사이트 사본에도 그 파일을 포함하고, CMS 템플릿의 메타 태그나 구글 애널리틱스를 이용했다면 해당 요소도 유지하도록 안내합니다.</p><p>운영자는 자신이 어떤 방식으로 인증했는지 모르면 관리 담당자에게 먼저 묻습니다. 담당자는 현재 인증 수단과 새 서버에 반영할 요소를 정리하고, 이전 뒤에도 소유권 인증이 작동하는지 시험합니다. 일반 페이지가 열리는지만 시험하는 작업과 관리 도구의 인증 상태를 검사하는 작업은 따로 요청합니다.</p></section><section id="section-8"><h2>자주 묻는 질문</h2><h3>실시간 검사에 경고가 있으면 이전 실패인가요?</h3><p>경고가 있다는 이유로 호스팅 이전 실패를 단정하지 않습니다. 서치 콘솔의 등록 가능하지만 문제가 있다는 상태는 색인 생성은 가능해도 일부 개선사항이 표시되지 않을 수 있다는 뜻입니다. 담당자에게 경고가 연결 문제인지 구조화된 데이터 같은 별도 항목인지 설명하도록 요청합니다.</p><h3>접속 시험용 주소도 검색에 등록될 수 있나요?</h3><p>공개된 시험용 주소는 검색 처리를 제한할 준비가 필요합니다. 구글 검색 센터는 시험 사이트가 실수로 색인에 포함되지 않도록 페이지 HTML이나 HTTP 헤더에 noindex 규칙을 추가하는 방법을 안내합니다. 담당자에게 시험용 주소와 실제 운영 주소에 적용할 설정을 각각 명시하도록 요청합니다.</p><h3>로봇 안내 파일을 읽지 못해도 문제가 되나요?</h3><p>구글은 robots.txt 파일이 존재하지만 가져올 수 없는 경우 사이트를 수집하지 않는다고 설명합니다. 서치 콘솔 도움말은 이 파일의 사용 가능 여부를 크롤링 통계 보고서에서 확인할 수 있다고 안내합니다. 담당자에게 파일의 존재 여부와 가져오기 실패 여부를 따로 설명하도록 요청합니다.</p><h3>이전 직후 검사 요청을 처리하지 못하면 어떻게 하나요?</h3><p>호스트 로드 초과 상태라면 사이트가 구글의 수집 또는 검사 요청을 처리하는 용량에 도달한 것으로 해석할 수 있습니다. 구글 도움말은 예상한 트래픽 부하가 줄어들 때까지 테스트를 실행할 수 없다고 설명합니다. 기술 담당자에게 부하 상태를 조사하도록 요청하고, 검사 불가 상태를 곧바로 검색 제외로 판단하지 않습니다.</p><h3>이전 뒤에 페이지의 색인 생성을 요청해야 하나요?</h3><p>호스팅 변경만을 이유로 모든 페이지에 색인 생성 요청을 해야 한다고 단정할 수는 없습니다. 서치 콘솔 도움말은 페이지가 색인에 반영된 버전과 다를 때 색인 생성을 요청하거나 사이트맵을 제출하고, 자연스러운 수집을 기다리는 방법도 설명합니다. 운영자는 페이지 내용까지 변경했는지 담당자에게 전달하고 필요한 후속 작업을 정합니다.</p></section>