본문으로 건너뛰기
J
피드

구글, '뒤로가기 버튼 하이재킹' 공식 스팸 정책 위반으로 지정 — 6월 15일부터 시행

frontend 약 3분
tags
#google#seo#spam-policy#web#browser
vote
0
댓글
북마크

구글이 브라우저 뒤로가기 버튼을 가로채는 행위를 스팸 정책의 '악의적 관행' 위반으로 명시했음. 위반 사이트는 수동 스팸 조치나 자동 검색 순위 강등을 받게 되며, 서드파티 라이브러리나 광고 플랫폼이 원인이어도 사이트 소유자 책임. 시행일은 2026년 6월 15일.

  • 1

    뒤로가기 버튼 하이재킹이 구글 스팸 정책 '악의적 관행' 위반으로 격상

  • 2

    위반 시 수동 스팸 조치 또는 자동 검색 순위 강등 적용

  • 3

    서드파티 광고 SDK나 라이브러리가 원인이어도 사이트 소유자 책임

  • 4

    2026년 6월 15일 시행 — 2개월 사전 유예 기간 제공

  • 구글이 "뒤로가기 버튼 하이재킹(back button hijacking)"을 공식 스팸 정책 위반으로 지정함
    • 사용자가 브라우저 뒤로가기를 눌렀을 때 이전 페이지로 못 돌아가게 막는 행위를 말함
    • 방문한 적 없는 페이지로 보내거나, 원치 않는 광고/추천을 띄우는 등의 패턴이 해당
    • 기존 Google Search Essentials에서도 금지였지만 이번에 "악의적 관행(malicious practices)" 정책 위반으로 명시적 격상

⚠️주의

> 시행일은 2026년 6월 15일. 사이트 운영자에게 변경 시간을 주기 위해 2개월 전 사전 공지하는 것이니, 해당되면 지금 바로 점검해야 함.

  • 위반 시 수동 스팸 조치(manual spam action) 또는 자동 강등(automated demotion)이 적용됨

    • 구글 검색 결과에서 사이트 노출이 직접적으로 타격받는다는 뜻
    • "이 정도면 괜찮겠지" 하고 넘기기엔 리스크가 꽤 큼

  • 핵심은 사이트 소유자가 직접 넣은 코드가 아니어도 책임진다는 점

    • 광고 플랫폼이나 서드파티 라이브러리가 뒤로가기를 가로채는 경우도 해당됨
    • 구글은 "기술 구현을 철저히 검토하고, 뒤로가기 하이재킹의 원인이 되는 코드나 설정을 제거하라"고 명시함
    • 광고 SDK 쓰는 사이트는 특히 한번 확인해봐야 함

💡팁

> 브라우저 히스토리에 history.pushState()나 history.replaceState()로 조작하는 코드가 없는지, 광고 스크립트가 히스토리를 건드리지 않는지 점검해볼 것.

  • 구글이 이번에 명시적으로 규정한 이유는 이런 행위가 늘어나고 있어서
    • 사용자들이 "조작당하는 느낌"을 받고 낯선 사이트 방문 자체를 꺼리게 된다는 게 구글의 문제 인식
    • 결국 웹 생태계 전체의 신뢰 문제로 번지는 걸 막겠다는 취지

국내 웹사이트 중 광고 스크립트가 히스토리를 조작하는 경우가 꽤 있는데, 이번 정책 변경 전에 점검이 필요함. SEO에 직접적으로 영향을 미치는 만큼 웹 프론트엔드 개발자와 마케팅팀 모두 알아야 할 소식.

prev

이전 기사 (P)

next

다음 기사 (N)

댓글

댓글

댓글을 불러오는 중...

관련 기사

frontend

요즘 픽셀 폰트가 그냥 복고 감성이 아닌 이유

1990년대 기기 화면 느낌을 현대 폰트 시스템으로 재해석한 픽셀 폰트 몇 가지를 소개한 글이다. 핵심은 예쁜 복고풍 글자 모양만이 아니라, 실제 제품에서 쓸 수 있게 기준선, 자간, 메타데이터, 세로 메트릭까지 챙기는지가 중요하다는 점이다.

frontend

HTML의 `<dl>`이 생각보다 쓸모 많은 이유

이 글은 HTML의 description list, 즉 `<dl>`, `<dt>`, `<dd>`가 단순 용어 사전용 태그가 아니라 이름-값 쌍 UI를 표현하는 꽤 강력한 시맨틱 도구라고 설명한다. 숙소 편의시설, 요금 내역, 기술 용어 설명, 게임 능력치표처럼 흔한 패턴을 중첩 `<div>` 대신 의미 있는 HTML로 만들 수 있다는 얘기다.

frontend

HTML을 캔버스 안에 넣는 데모 모음이 등장함

구글 크롬 랩스 저장소에 HTML-in-Canvas 관련 데모와 프레임워크 지원 목록이 정리됐다. Duck Hunt 스타일 폼, 흔들리는 버튼, 셰이더 기반 페이지 전환, 천처럼 매달린 폼 같은 실험적 예제가 포함돼 있고 Three.js와 PlayCanvas 쪽 샘플도 연결돼 있다.

frontend

싱글 페이지 앱이 웹을 너무 비싸게 만들었다는 불평

이 글은 싱글 페이지 앱(SPA)이 사용자 경험을 좋게 만든다는 명분 아래 웹의 초기 로딩 비용, 도구 복잡도, 개발 진입 장벽을 키웠다고 비판한다. 페이스북 로그인 페이지의 CSS 3.8MB, 레딧 몇 개 클릭 후 33MB 다운로드 같은 숫자를 들며, 지금의 프론트엔드 생태계가 사람보다 대기업의 요구에 맞춰져 있다고 주장한다.

frontend

네이티브로 끝까지 가려다 텍스트에서 막힌 macOS 개발자의 고백

20년 가까이 macOS와 iOS 네이티브 개발을 해온 작성자가 SwiftUI, AppKit, TextKit 2로 마크다운 채팅 UI를 만들다 결국 WebKit과 Electron 쪽이 훨씬 낫다는 결론에 도달한 글이다. 문제는 성능 하나가 아니라 선택, 스트리밍, 스크롤, 접근성, 텍스트 상호작용 같은 ‘사용자가 당연히 기대하는 기본기’가 네이티브 조합에서 계속 깨진다는 점이다.