페이지 소스에서 정식 접속주소 읽어내는 법: canonical·내부 링크로 최신주소 판정하기

화면이 똑같아도 소스는 다르다: 두 글자에서 멈춘 저녁

지난달 화요일 저녁, 메신저로 받은 접속주소를 열었더니 화면은 기억하던 그대로였다. 로고 위치도, 상단 배너의 문구도, 하단 안내문의 줄바꿈 지점까지 어긋난 데가 없었다. 문제는 주소창이었다. 도메인 중간의 두 글자가 내가 알던 것과 달랐고, 그것이 실제 도메인 변경인지 한 글자 바꿔치기한 복제본인지 판단할 근거가 화면 어디에도 없었다. 눈으로 아무리 비교해도 결론이 나지 않아서, 그날 처음으로 소스 보기를 눌렀다.

소스 안에는 화면에 그려지지 않는 주소가 최소 네 군데 박혀 있었다. 문서 상단의 canonical 태그, 공유용 og:url, 파비콘과 스타일시트 경로, 그리고 본문 곳곳의 내부 링크였다. 그중 세 군데가 주소창과 다른 도메인을 가리키고 있었고, 그 다른 도메인은 내가 원래 알던 주소와 정확히 일치했다. 복제본은 화면을 베끼는 데는 성공했지만 소스에 남은 원본 주소까지 전부 갈아끼우지는 못한 것이다. 이 글은 그날 이후 다듬은 판정 절차를 순서대로 옮긴 것이다.

시작 전 준비: 단축키 하나, 검색어 네 개, 메모 한 줄

필요한 도구는 브라우저뿐이다. PC 크롬·엣지·파이어폭스에서 Ctrl+U를 누르면 현재 페이지의 원본 HTML이 새 탭에 열린다. 맥은 Command+Option+U다. 열린 소스 화면에서 다시 Ctrl+F를 눌러 검색창을 띄우면 준비가 끝난다. 여기까지 걸리는 시간은 3초 남짓이고, 페이지에 로그인하거나 아무것도 클릭하지 않은 상태에서 해야 의미가 있다. 소스 보기는 페이지를 다시 요청하지 않고 이미 받아둔 문서를 보여주는 동작이라, 서버에 추가 흔적을 남기지 않는다.

검색할 문자열은 네 개로 충분하다. canonical, og:url, href=, 그리고 확인하려는 도메인의 앞 네 글자다. 마지막 항목이 중요한 이유는, 복제본이 원본 주소를 지우지 못한 채 남겨둔 자리를 한 번에 찾아주기 때문이다. 예를 들어 원래 알던 도메인이 abcd로 시작한다면 소스에서 abcd를 검색해 몇 건이 잡히는지 세면 된다. 0건이면 이 페이지는 원본과 아무 연관이 없고, 5건 이상 잡히면 원본 도메인을 그대로 베낀 흔적이 남아 있다는 뜻이다.

메모는 한 줄이면 된다. 오늘 날짜, 주소창에 보이는 도메인, 소스에서 나온 도메인 세 가지를 적어둔다. 이 기록이 쌓이면 한 달 뒤 다시 주소가 바뀌었을 때 직전 정본이 무엇이었는지 되짚을 수 있다. 판정 자체보다 이 기록이 더 오래 쓸모가 있었다는 게 몇 달 써본 소감이다. 기억에 의존하면 세 번째 변경쯤부터 순서가 섞인다.

여섯 단계로 정식 접속주소를 뽑아내는 절차

아래 순서는 앞 단계에서 결론이 나면 뒤를 생략해도 되도록 배치했다. 보통 2단계나 3단계에서 판정이 끝나고, 애매할 때만 5단계까지 간다. 전체를 다 돌려도 5분을 넘지 않는다.

1. 소스 열기 — 로그인 전, 아무 버튼도 누르지 않은 첫 화면에서 Ctrl+U를 누른다. 팝업이 먼저 떴다면 닫고 나서 다시 누른다.
2. canonical 찾기 — Ctrl+F로 canonical을 검색한다. link rel=canonical href= 뒤에 적힌 주소를 그대로 메모한다. 없으면 3단계로 넘어간다.
3. og:url 찾기 — og:url을 검색해 content= 뒤의 주소를 읽는다. 카카오톡·트위터에 링크를 붙였을 때 미리보기로 뜨는 주소가 이것이다.
4. 내부 링크 세기 — href=를 검색하면 브라우저가 전체 건수를 알려준다. 그중 외부 도메인이 절대주소로 박힌 건수를 세어 비율을 낸다.
5. 정적 자원 경로 확인 — 파비콘, CSS, 이미지 경로에 다른 도메인이 절대주소로 들어가 있는지 본다. 여기서 원본 흔적이 자주 걸린다.
6. 대조와 결론 — 2~5단계에서 나온 도메인 목록을 주소창 도메인과 비교한다. 과반이 주소창과 다른 곳을 가리키면 지금 열린 주소는 정본이 아니다.

실제로 돌려보면 4단계가 가장 판정력이 높다. canonical은 복제본 제작자가 가장 먼저 바꾸는 한 줄이지만, 본문에 흩어진 수십 개의 내부 링크를 전부 바꾸려면 원본을 통째로 다시 조립해야 하기 때문이다. 바꿔 말하면 canonical만 깨끗하고 내부 링크가 지저분한 페이지가 가장 의심스럽다.

canonical이 주소창과 다를 때 읽어야 할 세 갈래

canonical 태그는 원래 검색엔진에 이 문서의 대표 주소가 무엇인지 알려주는 용도다. 정상적으로 도메인을 옮긴 사이트라면 canonical도 새 도메인으로 함께 갱신된다. 그래서 주소창은 새 도메인인데 canonical만 옛 도메인을 가리킨다면 해석이 갈린다. 첫째, 이전 작업이 덜 끝나 캐시된 옛 템플릿이 남은 경우. 둘째, 옛 도메인 시절의 페이지를 통째로 복사해 새 껍데기에 붙인 복제본인 경우다.

두 경우를 가르는 기준은 canonical이 가리키는 옛 도메인이 지금 살아 있는지다. 옛 주소를 새 탭에서 열었을 때 새 도메인으로 자동 이동하면 첫째 상황에 가깝다. 반대로 옛 주소가 연결되지 않거나 전혀 다른 페이지를 띄운다면, 복제본이 이미 죽은 도메인의 소스를 그대로 베낀 상황일 가능성이 크다. 죽은 도메인을 canonical로 달고 있는 페이지에 계정 정보를 입력하는 건 가장 피해야 할 조합이다.

세 번째 갈래도 있다. canonical이 주소창과 완전히 무관한 제3의 도메인, 그것도 전혀 다른 업종의 주소를 가리키는 경우다. 이건 만들어둔 템플릿을 사서 쓰면서 원본 제작자의 주소를 지우지 않은 흔적이다. 판정 자체는 간단하다. 어느 쪽 주소도 믿을 근거가 없으니 다시 처음부터 공식 안내 경로에서 주소를 받아오는 게 빠르다.

내부 링크 집계: 48개 중 41개가 말해준 것

앞서 말한 저녁의 사례로 돌아가면, href=를 검색했을 때 브라우저가 알려준 총 건수는 63건이었다. 이 중 상대경로(/로 시작하거나 파일명만 적힌 것)가 15건, 도메인이 통째로 박힌 절대주소가 48건이었다. 판정에 쓰는 건 절대주소 48건이다. 여기서 주소창 도메인을 포함한 링크는 7건뿐이었고, 나머지 41건은 전부 내가 원래 알던 옛 도메인을 가리키고 있었다.

비율로 보면 85%다. 정상적으로 도메인을 이전한 사이트라면 이 비율이 반대로 나온다. 내부 링크의 90% 이상이 현재 주소창 도메인이거나 아예 상대경로로 쓰여 있어야 한다. 상대경로 비중이 높을수록 오히려 건강한 신호인데, 도메인을 자주 바꾸는 사이트일수록 링크를 상대경로로 짜두어야 이전 작업이 수월하기 때문이다. 절대주소가 수십 건씩 박혀 있다는 건 그 문서가 특정 도메인에 묶인 채 복사됐다는 뜻이다.

기준선을 하나 정해두면 판단이 빨라진다. 절대주소 링크 중 현재 도메인 비중이 70% 미만이면 정본으로 보지 않는다는 선이다. 실측해 보면 정상 이전 직후의 페이지도 92~98% 사이에서 나오고, 복제본은 대부분 30% 아래로 떨어진다. 그 사이 회색지대가 넓지 않아서 70%는 꽤 넉넉한 기준이다.

og:url과 파비콘 경로를 겹쳐 읽기

og:url은 메신저나 SNS에 링크를 붙였을 때 뜨는 미리보기 카드의 기준 주소다. 사용자에게 직접 보이지 않는 값이라 복제본 제작자가 놓치는 빈도가 canonical보다 높다. 실제로 canonical은 새 도메인으로 바꿔놓고 og:url만 옛 도메인이 남아 있는 페이지를 여러 번 봤다. 두 값이 서로 다르다면, 그 자체로 이 문서가 한 번에 만들어진 게 아니라 부분 수정됐다는 증거가 된다.

파비콘과 스타일시트 경로도 같은 원리로 읽는다. 소스에서 favicon을 검색해 href 값이 /favicon.ico 같은 상대경로면 정보가 없는 것이고, 다른 도메인의 절대주소면 그 도메인이 진짜 원본일 확률이 높다. 이미지 서버를 별도 도메인으로 쓰는 사이트도 있으니 이것 하나로 단정하진 않는다. 다만 canonical·og:url·파비콘이 모두 같은 제3 도메인을 가리킨다면, 지금 열린 주소는 그 도메인의 껍데기를 빌려 쓴 페이지로 보는 게 맞다.

소스가 거의 비어 있을 때: 스크립트가 그리는 페이지

Ctrl+U로 열었는데 스무 줄 남짓한 코드와 script 태그 몇 개만 보이는 경우가 있다. 화면 내용을 자바스크립트가 나중에 그려 넣는 구조라 원본 HTML에는 아무것도 없는 것이다. 이때는 소스 보기 대신 개발자도구를 쓴다. F12를 누르고 Elements 탭으로 가면 실제로 그려진 결과물이 보이고, 거기서 Ctrl+F로 같은 검색을 하면 된다.

더 간단한 대안은 Network 탭이다. F12를 연 상태로 페이지를 새로고침하면 이 페이지가 어느 도메인들에서 파일을 받아오는지 목록으로 쌓인다. 목록 상단의 Domain 열을 보면 주소창과 다른 도메인이 몇 개나 끼어 있는지 한눈에 들어온다. 정상 사이트도 CDN이나 통계 스크립트 때문에 외부 도메인이 2~5개 정도는 나오지만, 본문 이미지와 CSS까지 전부 다른 한 도메인에서 받아온다면 그쪽이 원본이다.

이 방식의 부수효과가 하나 있다. Network 목록에서 문서 요청의 상태코드를 함께 볼 수 있어서, 중간에 리다이렉트가 몇 번 일어났는지도 드러난다. 주소창에는 최종 도착지만 남지만 목록에는 거쳐온 주소가 전부 줄줄이 남는다. 경유지가 세 곳 이상이면 어느 단계에서 주소가 바뀌었는지 되짚어볼 값이 생긴다.

모바일에서 소스를 여는 우회 경로와 한계

안드로이드 크롬은 주소창에 view-source: 를 직접 입력하는 방식이 막혀 있다. 대신 주소창에 보이는 주소를 길게 눌러 복사한 뒤, 새 탭 주소창에 view-source:를 먼저 치고 붙여넣으면 열리는 경우가 있다. 버전에 따라 동작이 갈리니 안 되면 고집할 필요는 없다. 아이폰 사파리는 기본적으로 소스 보기를 제공하지 않는다.

모바일에서 가장 현실적인 방법은 그 주소를 메모앱에 복사해두었다가 PC에서 확인하는 것이다. 급하면 공유 메뉴로 자기 자신에게 링크를 보내 미리보기 카드에 뜨는 도메인을 보는 우회도 있다. 이 카드는 og:url을 참조하므로, 카드에 적힌 도메인이 내가 방금 연 주소와 다르면 그 시점에 이미 이상 신호다. 미리보기 카드가 아예 생성되지 않는 링크는 판정 재료가 없는 것이지, 그 자체로 위험 신호는 아니다.

마지막 5분, 세 숫자로 결론 내기

판정을 끝낼 때는 숫자 세 개만 남긴다. 절대주소 링크 중 현재 도메인 비중(앞의 예에서 15%), canonical·og:url·파비콘 중 현재 도메인을 가리킨 항목 수(0/3), 그리고 원본 의심 도메인이 소스에 등장한 총 횟수(41회)다. 이 세 값이 한 줄로 적히면 며칠 뒤에 봐도 그때 왜 그렇게 판단했는지 복원된다.

그날의 결론은 명확했다. 15%, 0/3, 41회. 화면은 완벽했지만 소스는 전혀 다른 이야기를 하고 있었다. 나는 그 주소를 닫고 원래 알던 도메인을 직접 입력해 들어갔고, 그쪽에서 같은 검사를 돌렸을 때는 96%, 3/3, 0회가 나왔다. 두 결과의 간격이 너무 커서 더 고민할 여지가 없었다.

덧붙이자면 이 숫자는 절대 점수가 아니라 대조값이다. 후보 주소가 둘 이상일 때 같은 방식으로 측정해 나란히 놓는 순간 판정력이 생긴다. 하나만 재서 몇 점인지 따지는 것보다, 두 후보의 비율 차이를 보는 편이 훨씬 빠르고 덜 틀린다.

이 방법이 통하지 않는 순간

소스 대조가 무력해지는 상황이 두 가지 있다. 첫째, 복제본이 원본 서버의 응답을 실시간으로 받아 그대로 중계하는 구조일 때다. 이 경우 소스에 박힌 도메인이 원본과 완전히 일치하므로 내부 링크 비율은 깨끗하게 나온다. 다만 이런 구조는 링크를 눌렀을 때 주소창 도메인이 원본으로 튀어버리는 일이 잦아서, 내부 링크 두세 개를 실제로 눌러보면 드러난다.

둘째, 원본 사이트가 애초에 내부 링크를 전부 상대경로로만 쓰고 canonical·og:url도 달지 않은 경우다. 판정 재료가 0이니 소스를 열어도 얻을 게 없다. 이때는 도메인 등록 이력이나 인증서 발급 시점 같은 바깥쪽 근거로 넘어가야 한다. 소스 읽기는 빠르고 비용이 없다는 게 장점이지, 모든 상황을 덮는 방법은 아니다.