robots.txt·sitemap 확인으로 웹사이트 운영 구조 분석하는 방법

이 사이트는 어떤 콘텐츠 유형을 운영하고, 검색엔진에는 무엇을 공개하려 할까요? 관리자 화면에 접근하지 않아도 /robots.txt와 sitemap처럼 누구나 볼 수 있는 파일에서 일부 단서를 얻을 수 있습니다. 다만 공개된 크롤링 규칙과 URL 목록은 운영 구조의 일부만 보여줄 뿐, 비공개 페이지나 실제 색인 상태, 운영자의 의도까지 증명하지는 않습니다.

robots.txt와 sitemap이 보여주는 정보는 다르다

robots.txt는 크롤링 요청을 조정한다

robots.txt는 사이트 루트에 놓이는 공개 텍스트 파일이다. 검색엔진 로봇을 뜻하는 User-agent와 접근 규칙인 Allow, Disallow를 조합해 어느 경로를 크롤링할 수 있는지 안내한다. 주된 목적은 크롤링 요청 관리이지 비밀 정보를 감추거나 검색 결과에서 URL을 완전히 제거하는 것이 아니다. 자세한 원칙은 Google의 robots.txt 안내에서도 확인할 수 있다.

예를 들어 Disallow: /search/가 보인다면 해당 크롤러에 내부 검색 경로를 방문하지 말라고 요청한다는 사실까지는 말할 수 있다. 그러나 그 경로에 민감한 정보가 있다거나, 모든 로봇이 규칙을 준수한다거나, URL이 검색 결과에 절대 나타나지 않는다고 해석해서는 안 된다.

sitemap은 발견 가능한 URL의 목록을 제공한다

sitemap은 사이트가 검색엔진에 알리고 싶은 페이지·이미지·동영상·뉴스 URL과 관련 정보를 정리한 파일이다. 하나의 XML 파일에 URL이 나열될 수도 있고, 여러 하위 sitemap을 묶는 sitemap index가 먼저 나타날 수도 있다. 이 구조는 게시글, 페이지, 카테고리처럼 콘텐츠 묶음을 파악하는 데 유용하다.

하지만 sitemap 포함 여부는 색인 결과표가 아니다. URL 발견과 크롤링을 돕는 힌트이므로, 포함된 주소가 모두 크롤링되거나 검색 결과에 노출된다고 보장할 수 없다. 반대로 내부 링크가 잘 구성된 소규모 사이트는 별도 sitemap이 없어도 검색엔진이 주요 URL을 발견할 수 있다.

robots.txt를 브라우저와 명령줄에서 확인하는 방법

루트 경로와 HTTP 응답을 함께 확인한다

브라우저 주소창에 https://example.com/robots.txt를 입력하는 것이 가장 간단하다. 반드시 도메인 바로 뒤의 루트 경로를 사용한다. https://example.com/blog/robots.txt처럼 하위 폴더에 임의로 붙인 주소는 해당 호스트 전체의 표준 robots.txt 위치가 아니다.

명령줄에서는 다음처럼 헤더와 본문을 나눠 확인할 수 있다.

curl -I https://example.com/robots.txt
curl -L https://example.com/robots.txt

-I는 HTTP 상태와 콘텐츠 유형, 리디렉션 여부를 확인할 때 유용하고, -L은 리디렉션을 따라가 최종 본문을 가져온다. 조사 기록에는 최초 주소, 최종 주소, 확인 시각, 상태 코드, 응답 본문 여부를 함께 남긴다. 404나 5xx가 나왔다고 해서 사이트 폐쇄, 의도적인 은폐 또는 특정 CMS 사용 여부를 뜻하지는 않는다. 일시적인 서버 오류나 접근 환경의 차이도 고려해야 한다.

User-agent, Allow, Disallow를 규칙 묶음으로 읽는다

User-agent: *는 일반적으로 모든 크롤러를 대상으로 하는 규칙 묶음을 뜻한다. 특정 로봇 이름이 적혀 있다면 그 로봇에 적용되는 별도 그룹일 수 있다. Disallow는 크롤링을 허용하지 않는 경로, Allow는 더 넓게 제한된 경로 안에서 허용하려는 예외 경로를 나타낼 수 있다.

• 지시어는 한 줄만 떼어 보지 말고 어느 User-agent 그룹에 속하는지 확인한다.
• 대소문자, 슬래시, 와일드카드 등 경로 표기를 원문 그대로 기록한다.
• 빈 Disallow:를 전체 차단으로 오해하지 않는다.
• 규칙에 등장한 경로를 관리자 페이지나 비밀 자료의 존재 증거로 표현하지 않는다.

Sitemap: https://example.com/sitemap.xml이 있다면 sitemap 후보 주소로 기록한 뒤 실제로 요청해 본다. 지시어가 여러 개면 각각 확인한다. 반대로 Sitemap 행이 없다고 해서 sitemap 자체가 없다고 확정할 수는 없다.

sitemap에서 콘텐츠 구조를 분류하는 순서

세 가지 후보 경로부터 확인한다

먼저 https://example.com/sitemap.xml과 https://example.com/wp-sitemap.xml을 확인하고, robots.txt에 별도 주소가 적혀 있다면 그 주소를 우선 대조한다. XML 대신 HTML 안내 페이지가 표시되거나 다른 경로로 이동할 수 있으므로 주소창의 최종 URL과 HTTP 응답도 기록한다.

최상위 파일에 여러 <sitemap>과 <loc>이 배열되어 있으면 sitemap index일 가능성이 크다. 각 loc이 가리키는 하위 파일을 열어야 실제 콘텐츠 URL을 볼 수 있다. 반면 <urlset> 아래에 여러 <url>과 <loc>이 있다면 개별 URL 목록이다.

URL과 메타 항목을 사실과 추정으로 나눈다

loc에는 대상 URL이 들어가며 lastmod는 sitemap 생성 시각이 아니라 연결된 페이지가 실제로 마지막 수정된 날짜를 나타내야 한다. 다만 구현 오류나 일괄 갱신 때문에 값이 정확하지 않을 수 있으므로 실제 페이지의 게시·수정 표시와 대조한다. changefreq는 예상 변경 빈도에 관한 참고 정보이지 크롤링 주기를 강제하는 명령이 아니다. priority 역시 같은 사이트 안 URL의 상대적 중요도에 대한 힌트일 뿐 검색 순위를 직접 정하지 않는다.

분류할 때는 파일명만 믿지 말고 URL 패턴과 표본 페이지를 함께 살핀다. 예를 들어 post-sitemap.xml, page-sitemap.xml, category-sitemap.xml이라는 이름은 각각 게시글·고정 페이지·카테고리 묶음의 단서가 된다. /tag/나 /author/ 패턴도 태그 및 작성자 아카이브 가능성을 보여준다. 그러나 파일 이름은 사이트가 임의로 정할 수 있으므로 대표 URL 몇 개를 브라우저에서 열어 페이지 성격을 확인해야 한다.

WordPress 사이트에서 wp-sitemap.xml을 해석하는 법

WordPress 5.5부터 코어에 기본 XML sitemap 기능이 포함됐으며 대표적인 index 경로는 /wp-sitemap.xml이다. 공개 조회가 가능한 글 유형과 분류 체계, 작성자 관련 sitemap 등이 구성될 수 있다. 따라서 이 경로가 정상 응답하면 WordPress 구조를 의심해 볼 만한 단서가 되지만, 그것만으로 현재 CMS와 전체 설정을 확정해서는 안 된다.

SEO 플러그인이 자체 sitemap을 만들면서 코어 sitemap을 비활성화하거나 다른 주소를 사용할 수도 있다. 테마, 플러그인, 공개 설정, 서버 규칙에 따라서도 결과가 달라진다. /wp-sitemap.xml이 404라고 해서 WordPress가 아니라고 결론 내릴 수 없으며, 정상 XML이라고 해서 모든 공개 콘텐츠가 빠짐없이 포함됐다고 볼 수도 없다.

sitemap이 보이지 않을 때는 robots.txt의 Sitemap 지시어, 홈페이지 소스와 주요 내비게이션, RSS 피드, 사이트 내부 검색, 검색엔진의 제한 검색 결과를 차례로 대조한다. 단, 제한 검색 결과는 색인 현황의 표본일 뿐 전체 URL 목록으로 취급하지 않는다.

운영 범위와 업데이트 패턴을 안전하게 추정하기

하위 sitemap별 URL 수를 세면 어느 콘텐츠 유형이 상대적으로 많이 공개돼 있는지 파악할 수 있다. 게시글 sitemap이 여러 파일로 분할되어 있고 페이지 sitemap은 하나라면 게시형 콘텐츠의 공개 규모가 더 클 가능성이 있다. 카테고리·태그·작성자 sitemap의 존재는 해당 아카이브 URL을 검색엔진 발견 대상으로 제공한다는 단서다.

lastmod 분포를 월별로 정리하면 최근에 변경된 URL이 어느 묶음에 집중되는지도 볼 수 있다. 그러나 이를 실제 발행 빈도, 편집 인력, 사업 성과로 곧바로 환산하면 안 된다. 템플릿 수정이나 데이터 이전으로 많은 날짜가 동시에 바뀔 수 있고, lastmod를 제공하지 않는 사이트도 정상적으로 운영될 수 있다.

각 유형에서 3~5개 URL을 표본으로 열어 제목, 본문 형태, breadcrumb, canonical 표기, 내비게이션 연결 여부를 확인하면 분류 정확도가 높아진다. 이때 공개 페이지의 구조만 살피고 로그인 우회, 숨겨진 파일 추측, 대량 요청과 같은 범위로 확장하지 않는 것이 중요하다.

조사 기록은 재현 가능하게 남긴다

스프레드시트에는 확인 URL, UTC 기준 시각, HTTP 상태, 최종 이동 주소, 콘텐츠 유형, 주요 지시어, 표본 URL, 관찰 내용과 해석을 각각 다른 열로 기록한다. 특히 “XML에서 직접 확인한 사실”과 “URL 패턴을 토대로 한 추정”을 분리하면 나중에 설정이 바뀌어도 판단 근거를 되짚기 쉽다.

• 확인 사실: 특정 시각에 URL이 200을 반환했고 post-sitemap.xml을 포함했다.
• 해석 가능한 단서: 게시글 형태의 공개 URL 묶음을 운영할 가능성이 있다.
• 확인 불가: 모든 게시글의 색인 여부, 방문자 수, 운영자의 SEO 의도는 알 수 없다.

현재 페이지와 과거 상태를 혼동하지 않는 것도 중요하다. 변경 또는 삭제된 URL을 조사한다면 삭제된 웹페이지의 과거 기록을 확인하는 방법을 참고해 보관 시점과 현재 응답을 별도로 적는다. 아카이브 사본은 특정 시점의 기록이며 지금의 설정을 증명하지 않는다.

특정 대상 사이트에서 홈페이지는 열리지만 robots.txt나 sitemap 직접 요청이 오류로 끝났다면, “이번 환경과 시각에서 내용을 확보하지 못했다”고만 기록하는 편이 정확하다. 그 결과를 사이트 폐쇄, WordPress 사용 여부, 악성 설정 또는 숨겨진 콘텐츠의 증거로 확대해서는 안 된다.

색인 차단과 보안을 혼동하지 않는다

robots.txt로 차단된 URL도 다른 페이지에서 링크되면 주소 자체가 검색 결과에 나타날 수 있다. 검색 제외가 목적이라면 페이지에 noindex를 제공하거나 인증으로 접근을 보호하거나 불필요한 페이지를 삭제하는 방법을 검토해야 한다. 단, 검색엔진이 noindex를 읽으려면 페이지를 크롤링할 수 있어야 하므로 같은 URL을 robots.txt로 막는 조합은 주의가 필요하다.

민감한 정보는 robots.txt의 준수 여부에 기대지 말고 인증과 권한 제어로 보호해야 한다. sitemap 역시 검색엔진을 위한 발견 보조 수단이지 접근 통제 목록이 아니다. 공개 파일에 URL이 없다는 사실도 그 URL이 존재하지 않는다는 증거는 아니다.

자주 묻는 질문

robots.txt만으로 특정 페이지의 색인을 완전히 막을 수 있나요?

아니다. robots.txt는 주로 크롤링 요청을 관리한다. 외부 링크 등을 통해 URL이 발견되면 본문을 크롤링하지 못한 상태에서도 주소가 검색 결과에 표시될 가능성이 있다. 검색 제외와 접근 보호는 목적에 맞는 별도 방법을 사용해야 한다.

sitemap이 없으면 WordPress 사이트가 아닌가요?

그렇게 판단할 수 없다. 기본 sitemap이 비활성화됐거나 플러그인이 다른 경로를 사용할 수 있고, 서버 오류나 접근 환경 때문에 확인되지 않을 수도 있다. CMS 판단에는 페이지 소스, 공개 리소스 경로와 HTTP 응답 등 복수의 단서가 필요하다.

lastmod는 실제 수정일과 항상 일치하나요?

표준상 연결된 페이지의 최종 수정일을 나타내야 하지만 구현이 항상 정확한 것은 아니다. 페이지에 표시된 날짜, RSS 항목, HTTP 헤더와 비교하고 값이 어떻게 생성됐는지 모르면 확정적인 수정 시각으로 쓰지 않는다.

공개 단서를 조합하되 결론의 범위를 지킨다

robots.txt·sitemap 확인은 웹사이트 운영 구조 분석을 시작하기 좋은 방법이다. 전자는 크롤링 규칙을, 후자는 검색엔진에 제공되는 URL과 콘텐츠 유형의 단서를 보여준다. 브라우저와 명령줄에서 응답을 확인하고, 게시글·페이지·카테고리·태그·작성자 아카이브별로 분류하면 공개 구조를 비교적 체계적으로 정리할 수 있다.

최종 결론은 파일에서 직접 확인한 사실까지만 단정해야 한다. URL 포함은 색인을 보장하지 않고, Disallow는 보안 기능이 아니며, 접근 오류도 사이트 상태나 운영 의도를 입증하지 않는다. 홈페이지 내비게이션, 실제 표본 페이지, RSS, 과거 아카이브와 공식 문서를 함께 대조할 때 비로소 신뢰할 수 있는 분석 기록이 완성된다.