google mobile friendly test 중단 후 모바일 최적화 여부를 어떻게 확인하나요?

Google은 2023년 12월에 google mobile friendly test 및 Search Console의 ‘모바일 사용 편의성’ 보고서를 중단했습니다. 기존의 ‘한 번 검사하여 모바일 친화 여부를 알려주는’ 기능이 사라졌다고 해서 모바일 최적화가 더 이상 색인 생성과 순위에 영향을 주지 않는 것은 아닙니다. Google은 여전히 주로 Smartphone Googlebot을 사용하여 웹페이지를 크롤링하고, 모바일 버전의 콘텐츠를 색인 및 평가의 기준으로 사용합니다.

실제로 대체해야 할 것은 녹색 ‘통과’ 표시 하나가 아니라 세 가지 판단입니다. Google이 모바일 페이지를 크롤링하고 렌더링할 수 있는지, 사용자가 실제 휴대폰 네트워크 환경에서 정상적으로 이용할 수 있는지, 페이지 속도와 레이아웃 안정성이 사용자 경험을 저해하는지입니다. 단일 도구로는 이 세 가지를 모두 확인할 수 없으므로, URL 검사, PageSpeed Insights 및 실제 기기 검증을 함께 사용하는 것이 더 안전한 방법입니다.

먼저 URL 검사로 확인: Google이 보는 페이지가 정상인지

Google Search Console의 ‘URL 검사’에 접속하여 전체 URL을 입력한 후, 우선 색인 생성된 버전을 확인합니다. 여기서 확인할 것은 자신의 컴퓨터에서 페이지가 열리는지가 아니라, Google이 최근 크롤링한 페이지가 색인 가능한지, 예상한 표준 페이지가 선택되었는지, 그리고 Smartphone Googlebot으로 크롤링되었는지입니다.

페이지를 방금 수정하여 아직 재크롤링되지 않았거나 Google의 읽기 결과가 브라우저와 다르다고 의심되는 경우, ‘실제 URL 테스트’를 사용할 수 있습니다. 크롤링 및 렌더링 결과를 중점적으로 확인해야 합니다. 스크린샷에 빈 영역, 주요 콘텐츠 누락, 팝업 차단, 스타일 오류 또는 오류 메시지가 나타난다면 문제는 대개 ‘화면 크기’가 아니라 리소스 로딩, 프런트엔드 렌더링 또는 접근 제한에 있습니다.

• JavaScript 의존성:첫 화면의 주요 콘텐츠, 제품 사양, 언어 전환 콘텐츠가 모두 스크립트의 비동기 로딩에 의존하는 경우, Google이 렌더링한 후 실제로 이러한 콘텐츠를 가져올 수 있는지 확인해야 합니다.
• 리소스 접근성:CSS, JavaScript, 이미지 CDN 또는 글꼴 파일이 robots.txt, WAF, 지역 제한 또는 로그인 검증으로 차단되면 Googlebot은 불완전한 페이지를 받게 됩니다.
• 반응형 일관성:데스크톱과 모바일에서 CSS 숨김으로 인해 핵심 제품 정보, 본문, 내부 링크 또는 구조화된 데이터가 누락되지 않도록 해야 합니다.
• 비정상 상태 코드:모바일 접속이 잘못 리디렉션되거나 4xx/5xx를 반환하거나 관련 없는 페이지로 이동하는 경우 모두 정상적인 크롤링에 영향을 미칩니다.

URL 검사는 ‘검색엔진이 볼 수 있는가’라는 질문에 적합하지만, 속도 테스트 도구는 아니며 사용자 조작 테스트를 대체할 수도 없습니다. 검사 결과가 정상이라는 것은 색인 생성 과정에 뚜렷한 장애가 없다는 의미일 뿐입니다.

PageSpeed Insights로 모바일 성능 및 레이아웃 문제 발견하기

PageSpeed Insights(PSI)는 일상적인 점검의 시작점으로 사용해야 합니다. URL을 입력한 후 ‘실제 사용자 데이터’와 Lighthouse 실험실 데이터를 구분하여 확인해야 합니다. 전자는 조건을 충족하는 Chrome 사용자 경험 데이터 세트에서 제공되며, 기존 방문에서의 경험을 반영합니다. 후자는 시뮬레이션된 모바일 환경에서 실행되므로 현재 페이지에서 재현 가능한 성능 문제를 파악하는 데 적합합니다.

모바일에서는 특히 세 가지 Core Web Vitals에 주목해야 합니다. LCP는 주요 콘텐츠가 표시되는 속도를, INP는 클릭·메뉴 펼치기·양식 제출 등의 상호작용 응답을, CLS는 페이지 로딩 중 요소가 흔들리는지를 반영합니다. 이것들이 ‘모바일 최적화’의 전부는 아니지만, 첫 화면의 대형 이미지 미압축, 과도한 타사 추적 스크립트, 콘텐츠를 밀어내는 Cookie 배너, 크기가 예약되지 않은 이미지 및 삽입 콘텐츠처럼 문의와 탐색에 영향을 주는 문제를 자주 드러냅니다.

PSI의 진단 권장 사항은 페이지의 실제 기능에 따라 판단해야 하며, 기계적으로 만점을 추구해서는 안 됩니다. 해외 무역 웹사이트에서 흔히 사용하는 다국어 스크립트, 고객 서비스 도구, 양식 검증, 지도 및 동영상은 모두 로딩 비용을 늘립니다. 더 가치 있는 처리 순서는 먼저 첫 화면의 핵심 콘텐츠와 문의 진입 경로를 사용할 수 있도록 보장하고, 그다음 이미지를 압축하고 비핵심 스크립트를 지연 로딩하며, 마지막으로 불필요한 타사 구성 요소를 제거할지 평가하는 것입니다.

브라우저 기기 모드는 1차 점검만 가능하며, 실제 기기 테스트는 여전히 생략할 수 없습니다

Chrome DevTools의 기기 도구 모음에서는 화면 너비, 픽셀 밀도 및 네트워크 속도 제한을 빠르게 전환할 수 있어 개편 시 중단점을 점검하는 데 적합합니다. 내비게이션이 올바르게 접히는지, 표가 가로로 넘치는지, 버튼이 잘리는지, 하단 고정 연락처가 양식을 가리는지 등을 확인할 수 있습니다. 장점은 효율성이 높다는 것이지만, 서로 다른 시스템 브라우저, 키보드 표시, 권한 팝업 및 실제 네트워크 변동을 완전히 시뮬레이션할 수 없다는 한계가 있습니다.

문의, 주문 또는 자료 다운로드와 관련된 페이지는 최소한 일반적인 모바일 브라우저에서 전체 경로 테스트를 완료해야 합니다. 검색 랜딩 페이지에서 진입하여 언어를 전환하고, 제품 상세 페이지를 열고, WhatsApp, 이메일 또는 양식을 클릭한 뒤 제출 후 성공 안내와 이메일 알림이 정상인지 확인해야 합니다. 많은 페이지가 시각적으로는 ‘최적화’되어 보이지만 국가 번호 입력란에서 숫자 키보드를 불러올 수 없거나, 인증 코드가 플로팅 버튼에 가려지거나, 첨부 파일 업로드가 실패하는 문제가 있습니다. 이러한 문제는 기존 mobile friendly test가 자동으로 식별하지 못합니다.

‘반응형 디자인’을 ‘모바일 적합’으로 잘못 판단하지 마세요

반응형 CSS는 화면 변화에 따라 레이아웃을 조정하는 문제를 해결할 뿐, 모바일 경험을 자동으로 해결하지는 않습니다. 일반적인 위험 요소로는 데스크톱 대형 이미지를 그대로 축소해 첫 화면 로딩이 너무 느려지는 경우, 제품 사양표를 휴대폰에서 읽기 어려운 경우, 메뉴 단계가 지나치게 깊은 경우, 작은 글씨와 빽빽한 링크로 오작동 터치가 발생하는 경우, 팝업 또는 광고가 주요 콘텐츠를 덮는 경우, 모바일에 과도한 애니메이션과 자동 재생 동영상이 남아 있는 경우 등이 있습니다.

Google 자연 검색 트래픽에 의존하는 페이지의 경우, 모바일 버전과 데스크톱 버전의 콘텐츠 신호가 일관적인지도 확인해야 합니다. 모바일에서 ‘간결함’을 위해 제품 모델, 적용 설명, FAQ, 이동 경로 및 관련 제품 링크를 삭제하면, Google이 모바일 버전으로 색인을 구축할 때 읽을 수 있는 정보도 줄어듭니다. 올바른 방법은 정보를 단순히 숨기는 것이 아니라, 접이식 영역, 앵커 내비게이션, 짧은 문단 및 가로 스크롤 가능한 표를 통해 읽는 방식을 개선하면서 크롤링 가능한 핵심 콘텐츠를 유지하는 것입니다.

색인 이상 발생 후 보완하지 말고 검사를 게시 프로세스에 포함하세요

테마를 변경하거나, 내비게이션을 수정하거나, 마케팅 스크립트를 연동하거나, 다국어 페이지를 추가하거나, CDN을 조정할 때마다 홈페이지, 핵심 제품 페이지, 콘텐츠 페이지 및 양식 랜딩 페이지를 표본 점검해야 합니다. 먼저 브라우저 기기 모드에서 레이아웃을 확인하고, PSI로 모바일 성능과 레이아웃 이동을 확인한 다음, 마지막으로 Search Console에서 중요한 URL에 대해 실제 URL 테스트를 수행합니다. 페이지가 이미 색인되었지만 트래픽 또는 노출에 이상이 있다면, Search Console의 ‘페이지 색인 생성’ 상태, 크롤링 시간 및 표준 페이지 정보를 함께 확인하여 문제 범위를 판단합니다.

google mobile friendly test가 중단된 후 검사는 일회성 ‘적합/부적합’에서 지속적인 검증으로 바뀌었습니다. 운영 실행 측면에서 가장 중요한 것은 완전히 동일한 대체 버튼을 찾는 것이 아니라 렌더링, 성능 및 전환 경로라는 세 가지 문제를 구분하는 것입니다. Google이 볼 수 없다면 먼저 크롤링과 리소스를 처리하고, 페이지가 느리게 열린다면 먼저 첫 화면과 스크립트를 처리하며, 사용자가 작업을 완료할 수 없다면 실제 기기 프로세스로 돌아가 항목별로 수정해야 합니다.