Google 검색 결과 HTML에서 목적지 주소를 바로 읽던 방식이 더 이상 안정적이지 않다. 검색 데이터 업체 Autom이 관찰한 새 형식은 결과 링크를 실제 웹사이트가 아니라 google.com/goto?url=...로 바꾼다. 사용자가 누르면 최종 페이지로 이동하지만 url 값은 평문 URL도, 단순한 base64 문자열도 아니다. 오프라인에서 바로 해독하기 어려운 Google 내부 참조값에 가깝다.

기존의 google.com/url?q=... 우회 링크와 차이가 분명하다. 예전 형식은 쿼리 문자열에서 목적지를 읽을 수 있었다. 새 형식에서는 /goto에 HEAD 요청을 보내고, 응답의 Location 헤더를 확인해야 한다. 실제 목적지까지 리디렉션을 따라갈 필요는 없지만 검색 결과 하나마다 Google에 요청이 한 번 더 생긴다. 수천 개 결과를 처리하는 크롤러라면 지연과 네트워크 비용, 차단 위험이 함께 커진다.

Autom은 2026년 8월 말 기준으로 로그아웃 상태와 비공개 브라우징에서 이 패턴이 일관되게 나타났다고 설명한다. 아직 모든 사용자에게 확정 적용된 정책인지, 대규모 실험인지는 Google이 공개하지 않았다. 검색 결과 화면에는 도메인과 파비콘을 그리기 위한 주소 단서가 남아 있어 다른 추출법도 가능하지만, 단순히 href만 읽는 구현은 깨진다. Autom은 자체 API에서 HEAD 응답을 읽어 최종 URL을 반환하도록 처리 절차를 바꿨다.

이 변화는 최근의 다른 제한과 맞물린다. Google은 한 번에 100개 결과를 요청하던 num=100 사용을 막고 BotGuard와 SearchGuard를 강화해 왔다. 새 우회 링크는 자동 수집을 완전히 막지는 못한다. 대신 링크 해석 행위를 Google 쪽에 보이게 만들고, 대량 요청자를 더 쉽게 식별하며, 소규모 도구가 감당해야 할 비용을 높인다. AI 검색 서비스와 SEO 분석 업체처럼 자체 색인을 만들지 않고 SERP에 의존하는 사업자에게 특히 직접적인 변화다.

커뮤니티의 관심은 기술적 우회법을 넘어 웹의 사용성으로 번졌다. 링크 위에 마우스를 올려 목적지를 확인하거나 오른쪽 클릭으로 진짜 주소를 복사하는 동작이 불투명해지고, 추가 리디렉션이 체감 지연을 만든다는 지적이다. 자원이 많은 수집업체는 새 요청을 병렬화해 대응할 수 있지만 개인 도구와 작은 검색 서비스는 더 불리해진다는 우려도 나왔다. 반대로 Google 입장에서는 결과를 대량 복제하는 자동화와 클릭 측정 문제를 동시에 다룰 수 있다.

개발자가 당장 확인할 것은 세 가지다. HTML 파서가 href를 최종 URL로 가정하는지, 리디렉션 응답을 안전하게 읽는지, 실패 시 도메인 표기 같은 보조 단서를 쓸 수 있는지다. HEAD 요청을 무제한으로 늘리면 새 차단 신호가 될 수 있으므로 캐시와 속도 제한도 필요하다. 자세한 관찰 내용은 Autom의 기술 글에 정리돼 있다.

#scraping

목적지 URL 감춘 google.com/goto, 검색 스크래핑 비용이 커진 이유