Hacker News, Google의 back button hijacking 스팸 정책 명문화에 주목

왜 Hacker News가 이 정책을 반겼나

관련 HN 스레드는 크롤링 시점에 678점, 403개 댓글을 기록했고, 분위기는 의외로 단순했다. 사람들은 이것을 새로운 SEO 테크닉이 아니라, 오래전부터 짜증을 유발해 온 웹 dark pattern에 대한 뒤늦은 제재로 읽었다. 댓글에는 Android의 “뒤로 가기 한 번 더 누르기”류 패턴이나 feed app의 과도한 history 개입을 떠올리는 반응도 있었고, Firefox 설정으로 pushState를 막을 수 있다는 우회법도 공유됐다. 하지만 HN의 큰 흐름은 사용자에게 설정 팁을 요구하는 것이 아니라, 검색 플랫폼이 문제를 명시적으로 잡기 시작했다는 데 의미를 뒀다.

Google이 실제로 적은 내용

Google Search Central Blog는 2026년 4월 13일, “back button hijacking”을 spam policies의 malicious practices 항목 아래에 두는 명시적 위반으로 적어 두었다. 글의 정의에 따르면, 이는 사이트가 사용자의 browser history에 deceptive하거나 manipulative한 페이지를 끼워 넣어 뒤로 가기 버튼을 눌렀을 때 원래 보던 페이지로 즉시 돌아가지 못하게 만드는 행위다. Google은 이런 페이지가 manual spam actions 또는 automated demotions의 대상이 될 수 있다고 적었고, site owner가 수정할 시간을 주기 위해 enforcement는 2026년 6월 15일부터 시작한다고 밝혔다. 중요한 포인트는 원인이 site 본문 코드뿐 아니라 포함된 library나 advertising platform일 수도 있다는 점이다.

왜 단순 UX 공지가 아닌가

이 정책은 단순히 “나쁜 습관을 쓰지 말라”는 블로그 조언과 다르다. Google은 browser history를 조작해 사용자의 기대를 깨는 행위를 이제 search performance에 직접 연결했다. 즉 뒤로 가기 방해가 더 이상 annoying UX 차원에 머무르지 않고, ranking risk와 연결되는 operational issue가 된 셈이다. HN에서 이 점이 크게 받아들여진 이유도 여기 있다. 사용자는 브라우저 내부 동작이나 pushState API를 디버깅하며 웹을 써야 할 이유가 없고, 플랫폼이 검색 노출을 통해 압박해야 이런 패턴이 줄어든다는 것이다.

사이트 운영자에게 남는 과제

Google의 글은 site owner에게 단순히 자사 코드만 보지 말고 포함된 script, ad tech, third-party library, configuration까지 점검하라고 요구한다. 이것도 중요한 변화다. 실제 서비스에서는 직접 작성한 코드보다 외부 모듈이 history를 건드리는 경우가 적지 않기 때문이다. 그래서 이번 정책은 SEO 담당자만의 이슈가 아니라, 프런트엔드 구현과 ad stack, third-party integration까지 함께 보는 문제로 읽어야 한다. HN이 이 소식을 고신호로 본 이유는, 웹의 매우 오래된 조작 패턴 하나가 드디어 이름 붙여지고, 검색 정책 차원에서 비용이 생기기 시작했기 때문이다.

출처: Google Search Central Blog · Hacker News 토론