4장. 애드센스 승인용 글과 수익형 글, 처음부터 따로 설계해야 합니다

모바일 기술 SEO는 PageSpeed 점수 하나를 높이는 작업이 아닙니다. 실제 방문자가 첫 답을 언제 읽고 메뉴나 링크를 언제 조작할 수 있는지, 로딩 도중 글과 광고가 얼마나 움직이는지, Googlebot이 렌더링한 화면에도 같은 본문과 이미지 문맥이 남는지를 함께 확인해야 합니다. 특히 Blogger는 호스팅 계층을 직접 바꾸기 어려운 대신 테마, 게시물 이미지, 위젯, 광고 및 분석 스크립트의 조합을 통제할 수 있습니다.

이 글은 느린 모바일 페이지를 측정하고 원인을 분리한 뒤 안전하게 되돌릴 수 있는 발행 운영 절차를 설명합니다. Core Web Vitals를 통과해도 검색 순위나 광고 수익이 보장되지는 않습니다. 좋은 수치는 사용자 경험의 일부를 관찰하는 기준이며, 콘텐츠 관련성·검색 수요·광고 배치·방문자 의도 같은 다른 조건을 대신하지 않습니다.

현장 데이터로 문제가 발생하는 사용자군을 찾고, 실험실 데이터로 원인 후보를 재현합니다. 수정은 한 번에 하나씩 적용하며, 점수가 올라도 본문·링크·광고·측정 기능이 망가지면 즉시 되돌립니다.

증상을 로딩·반응·안정성·누락으로 나눕니다

첫 화면의 대표 이미지나 제목이 늦게 나타나는 현상은 로딩 문제입니다. 메뉴 버튼을 눌러도 한동안 반응이 없거나 입력 뒤 화면 갱신이 늦는 현상은 상호작용 문제입니다. 광고가 뒤늦게 들어오며 읽던 문장을 아래로 밀거나 웹폰트 교체 후 제목 줄 수가 달라지는 현상은 시각적 안정성 문제입니다. 모바일에서 본문, 목차, 내부 링크가 아예 사라지는 현상은 속도 점수보다 렌더링 또는 반응형 테마 결함에 가깝습니다.

진단표에는 공개 URL, 측정 시각, 기기와 화면 폭, 브라우저, 네트워크 조건, 로그인 여부, 동의 배너 상태, 관찰된 요소를 남깁니다. 같은 템플릿의 정상 글과 문제 글을 각각 한 개 이상 고르면 사이트 전체 변경과 게시물 자산 문제를 구분하기 쉽습니다. 이미지가 많은 글만 느리면 원본 크기와 요청 순서를 먼저 보고, 모든 글이 같은 시점부터 느려졌다면 최근 테마 편집, 광고 설정, 태그 관리자, 위젯 추가를 먼저 조사합니다.

서버 응답, 자원 다운로드, 브라우저 실행, 최종 화면을 한데 섞지 않는 것도 중요합니다. HTML 응답은 빠르지만 거대한 이미지 때문에 첫 화면이 늦을 수 있고, 화면은 빨리 보여도 긴 자바스크립트 작업 때문에 메뉴가 멈출 수 있습니다. 반대로 점수는 양호해도 CSS 미디어 쿼리가 본문을 숨기면 모바일 검색 사용자는 답을 얻지 못합니다. 먼저 어떤 단계가 실패했는지 문장으로 정의해야 적절한 측정 도구를 고를 수 있습니다.

field data와 lab data를 다른 질문에 씁니다

field data는 실제 Chrome 사용자의 기기, 네트워크, 지역, 캐시 상태가 섞인 관측값입니다. Search Console Core Web Vitals와 Chrome UX Report 계열 데이터는 실제 경험의 분포와 URL 그룹 추세를 찾는 데 알맞습니다. 다만 트래픽이 적은 URL은 데이터가 없거나 비슷한 페이지 묶음으로 집계될 수 있고, 새 배포가 즉시 반영되지 않으며, Chrome 밖의 브라우저 경험을 완전히 대표하지도 않습니다. 보고서에 행이 없다는 사실은 페이지가 빠르다는 판정이 아닙니다.

lab data는 정해진 기기·네트워크 조건에서 실행한 Lighthouse, PageSpeed Insights 진단 또는 DevTools 기록입니다. 배포 전후를 빨리 비교하고 워터폴, 렌더링 차단 자원, LCP 후보, 긴 메인 스레드 작업을 찾는 데 유용합니다. 그러나 단 한 번의 테스트는 실제 방문자의 다양한 환경과 페이지 전체 상호작용을 대변하지 못합니다. 확장 프로그램, 테스트 위치, 서버 변동, 캐시 여부에 따라 값이 달라지므로 동일 조건에서 여러 차례 측정하고 중앙 경향과 반복되는 원인을 봅니다.

운영 흐름은 현장 경고에서 문제 페이지군과 사용자 분포를 찾고, 랩에서 대표 URL을 재현하며, 필요하면 자체 실사용자 측정으로 어떤 버튼이나 요소가 느렸는지 좁히는 순서가 안전합니다. 랩 결과가 좋아졌다는 것은 수정 방향을 빠르게 확인한 증거이지 현장 문제가 이미 해결됐다는 증거가 아닙니다. 반대로 현장 수치가 나쁘다고 고성능 개발자 휴대전화에서 반드시 같은 현상이 눈에 보이는 것도 아닙니다.

LCP·INP·CLS 기준과 측정 한계를 읽습니다

Google의 Core Web Vitals 안내는 좋은 경험의 목표를 실제 방문 기준 75번째 백분위에서 LCP 2.5초 이내, INP 200밀리초 이하, CLS 0.1 이하로 제시합니다. LCP는 초기 뷰포트에서 가장 큰 콘텐츠가 그려지는 시점, INP는 방문 중 일어난 상호작용들의 입력 지연·처리·다음 페인트를 아우르는 반응성, CLS는 예상하지 못한 레이아웃 이동의 누적을 관찰합니다. 세 지표는 각각 다른 사용자 문제를 가리키므로 하나의 합성 점수로만 읽지 않습니다.

LCP가 느리다고 무조건 이미지 압축부터 할 수는 없습니다. 후보가 텍스트 블록일 수 있고, 서버 응답, 렌더링 차단 CSS, 폰트, 이미지 발견 지연, 광고가 함께 영향을 줄 수 있습니다. INP는 실제 상호작용을 필요로 하므로 초기 로드만 수행하는 랩 테스트가 그대로 측정하기 어렵습니다. 실험실의 Total Blocking Time과 긴 작업은 원인 후보를 찾는 대리 신호일 뿐 INP와 같은 값이 아닙니다. CLS도 테스트 직후가 아니라 스크롤, 광고 갱신, 쿠키 배너 표시 뒤에 발생할 수 있습니다.

공식 임계값은 진단의 공통 언어이지 사업 성과의 약속이 아닙니다. 기준을 통과한 두 페이지 사이에서 더 빠른 숫자가 자동으로 더 높은 순위나 더 많은 수익을 얻는다고 단정할 수 없습니다. 반대로 관련성 높은 콘텐츠가 기준을 넘었다는 이유만으로 검색에서 사라진다고 말할 수도 없습니다. 운영자는 점수와 함께 첫 답 도달 시간, 메뉴 성공률, 읽기 중 이동, 이탈과 전환을 별도 관찰해야 합니다.

Blogger 테마와 서드파티 비용을 분해합니다

Blogger 페이지는 게시물 HTML만으로 완성되지 않습니다. 테마가 헤더·본문·사이드바·관련 글을 만들고, 플랫폼 스크립트에 광고 네트워크, 분석 태그, 댓글, 공유 버튼, 폰트, 외부 임베드가 더해집니다. 따라서 성능 워터폴을 출처별로 분류합니다. Blogger 또는 테마 자체 자원, 운영자가 넣은 게시물 이미지, 광고, 분석, 소셜 위젯, 웹폰트, 동영상 임베드로 나누면 제거 가능한 비용과 플랫폼 제약을 구별할 수 있습니다.

테마 원인은 모든 게시물에서 반복되는 렌더링 차단 스타일, 과도한 DOM, 사용하지 않는 슬라이더, 중복된 모바일·데스크톱 마크업으로 드러날 수 있습니다. 서드파티 스크립트는 다운로드 바이트보다 DNS 연결, 파싱, 실행, 동적 DOM 삽입 비용이 더 클 수 있습니다. 광고는 네트워크 요청과 경매뿐 아니라 늦은 슬롯 크기 확정으로 레이아웃을 움직일 수 있고, 폰트는 다운로드 지연과 대체 글꼴 교체로 제목의 폭과 높이를 바꿀 수 있습니다.

브랜드 이름만 보고 특정 태그를 범인으로 정하지 않습니다. DevTools Network의 도메인·시작 시각·전송 크기와 Performance의 긴 작업·호출 스택을 함께 확인합니다. 위젯을 끈 테스트, 광고를 제한한 진단 표본, 시스템 폰트로 바꾼 복제 환경을 각각 비교하되 실제 사이트에서 정책 위반 방식으로 광고 호출이나 사용자 행동을 조작하지 않습니다. 가치 있는 기능도 있으므로 비용과 기능 손실을 함께 기록합니다.

LCP 이미지의 요청 경로와 우선순위를 봅니다

모바일 첫 화면에서 가장 큰 요소가 대표 이미지라면 요청이 언제 발견되는지부터 봅니다. HTML의 일반 이미지로 즉시 발견되는지, CSS 배경이나 자바스크립트 실행 뒤에야 URL이 생기는지, 리디렉션을 거치는지, 첫 화면인데 지연 로드되는지 확인합니다. 서버 응답 뒤 오랫동안 요청이 시작되지 않는다면 압축률보다 발견과 우선순위 문제가 앞섭니다. 요청은 일찍 시작되지만 완료가 늦다면 실제 전송 바이트, CDN 응답, 원본 해상도와 표시 폭을 비교합니다.

Blogger 이미지 URL은 크기 변형을 제공할 수 있으므로 편집기에 업로드한 원본 크기만 보지 말고 공개 게시물의 최종 요청 URL과 응답 크기를 확인합니다. 폭 360픽셀 화면에 수천 픽셀 원본을 그대로 보내면 데이터와 디코딩 비용을 낭비합니다. 반대로 화면 캡처의 글자나 차트가 흐려질 만큼 일괄 압축하면 정보 전달이 망가집니다. 사진, 로고, 선화, 투명 이미지, 글자가 많은 캡처를 용도별로 나누고 WebP·AVIF 같은 현대 형식에는 호환 가능한 대체 경로를 고려합니다.

대표 이미지를 무조건 preload 하는 것도 해답은 아닙니다. 실제 LCP 후보가 아니거나 화면마다 다른 자산인데 잘못 앞당기면 중요한 CSS와 폰트의 대역폭을 경쟁시킵니다. 공개 테마의 모바일 화면에서 후보를 확인한 뒤 적용하고, 변경 전후 워터폴에서 요청 시작·완료와 LCP 요소가 실제로 달라졌는지 읽습니다. Googlebot이 브라우저의 모든 자원 힌트를 사용자와 같은 방식으로 소비한다고 가정해 SEO 보장 문구를 만들지 않습니다.

반응형 이미지의 크기·비율·alt를 설계합니다

반응형 이미지는 화면에 맞춰 CSS 폭만 줄이는 것과 다릅니다. 브라우저가 뷰포트와 픽셀 밀도에 적합한 파일을 고를 수 있도록 여러 후보 크기와 표시 조건을 제공해야 불필요한 원본 전송을 줄일 수 있습니다. Blogger 편집 결과가 일반적인 src만 제공하는지, srcset과 sizes가 있는지 공개 HTML에서 확인하고, 후보 URL이 실제로 존재하는지 점검합니다. 표준 img의 src 폴백은 이미지 발견성과 호환성을 위해 유지합니다.

width와 height 또는 안정적인 aspect-ratio로 로드 전 공간을 예약하면 이미지가 도착한 뒤 본문이 밀리는 현상을 줄일 수 있습니다. 숫자는 파일의 고정 표시 폭을 강제하기 위한 것이 아니라 고유 비율을 브라우저에 알려 주기 위한 값으로 사용할 수 있습니다. 테마 스타일에서 최대 폭을 컨테이너에 맞추고 높이를 자동 조정하되, 세로 이미지·캡션·회전 화면에서도 비율이 유지되는지 확인합니다. 광고나 임베드에도 같은 공간 예약 원칙을 적용합니다.

alt는 키워드 목록이나 파일명의 복사본이 아니라 이미지를 보지 못하는 독자가 잃는 정보를 짧게 설명합니다. 장식용 구분 이미지는 빈 대체 설명이 적절할 수 있고, 차트는 비교 대상과 결론을 본문 텍스트에도 적어야 합니다. 화면 캡처라면 “설정 화면”보다 어떤 항목을 어디서 확인해야 하는지 문맥에 맞게 설명합니다. Google 이미지 권장사항에 따라 의미 있는 이미지를 관련 문단 가까이에 두고, 중요한 제목이나 결론을 픽셀 안에만 가두지 않습니다.

lazy loading은 첫 화면 밖에 선택 적용합니다

지연 로딩은 초기 뷰포트 밖의 이미지와 iframe 요청을 뒤로 미뤄 초기 전송 경쟁을 줄이는 방법입니다. 첫 화면의 대표 이미지까지 일괄적으로 loading="lazy" 처리하면 LCP 후보 요청이 늦어질 수 있습니다. 글 상단 이미지, 로고, 첫 답에 필요한 도표는 실제 모바일 뷰포트에서 즉시 필요한지 판단하고, 긴 글 아래쪽 사진과 동영상 임베드처럼 나중에 보게 되는 자산에 우선 적용합니다.

Google의 지연 로드 안내처럼 스크롤이나 클릭을 해야만 이미지 URL이 생성되는 구현은 피합니다. 사용자가 뷰포트에 접근하면 자동으로 로드되고, 일반 HTML에서 이미지와 대체 설명을 발견할 수 있어야 합니다. 자바스크립트가 실패하더라도 중요한 본문이 남는지 확인합니다. URL 검사 스크린샷 한 장에 이미지가 없다는 이유만으로 이미지 색인 실패를 확정하지 말고, 렌더링 DOM·요청·실제 이미지 검색 상태를 함께 봅니다.

Blogger 기본 동작, 테마 스크립트, 별도 최적화 코드가 같은 이미지에 중복 지연 로딩을 걸 수 있습니다. 이 경우 관찰자가 두 번 붙거나 실제 src가 계속 자리표시자로 남는 오류가 생길 수 있습니다. 원본 img 속성, 렌더링 뒤 속성, Network 요청 시점을 순서대로 읽고 어느 계층이 로드를 담당하는지 하나로 정리합니다. 초기 전송량이 줄었어도 스크롤 중 이미지가 늦게 튀어나와 읽기 흐름을 깨면 추가 조정이 필요합니다.

광고·폰트·동적 삽입의 이동 원인을 찾습니다

CLS 문제는 이미지 치수 누락만으로 끝나지 않습니다. 상단 광고가 늦게 확장되거나 빈 광고 슬롯이 접혔다 다시 열리고, 동의 배너가 본문 위에 삽입되며, 관련 글 위젯이 높이를 뒤늦게 계산하면 읽던 위치가 이동합니다. 어떤 요소가 움직였는지와 무엇이 그 요소를 밀었는지는 다를 수 있으므로 Performance 기록의 Layout Shift 항목과 전후 스크린샷을 함께 봅니다.

광고 슬롯은 가능한 범위에서 예상 공간을 예약하고, 모바일 크기에 맞지 않는 고정 최소 높이가 과도한 공백을 만들지 점검합니다. 광고가 채워지지 않았을 때 공간을 접는 정책은 늦은 재요청과 함께 이동을 만들 수 있으므로 네트워크 동작과 배치 규칙을 같이 확인합니다. 수익을 높이려고 본문을 가리는 고정 광고나 오클릭을 유도하는 배치를 사용하지 않으며, CLS 개선이 광고 수익 증가를 보장한다고도 표현하지 않습니다.

웹폰트는 글꼴 파일 수, 문자 집합, 굵기별 요청, 외부 도메인 연결을 분해합니다. 대체 글꼴과 최종 글꼴의 자폭·행간 차이가 크면 교체 순간 제목과 본문 높이가 바뀝니다. 필요하지 않은 굵기와 아이콘 폰트를 줄이고 안정적인 시스템 대체 글꼴을 지정한 뒤 한글, 숫자, 영문 혼합 제목에서 줄바꿈을 검사합니다. 폰트 로딩 전략 변경 후에는 빠른 화면만 보지 말고 느린 네트워크에서 보이지 않는 텍스트 시간이 길어지지 않는지도 봅니다.

렌더링된 DOM과 Googlebot 화면을 비교합니다

원본 HTML은 서버가 보낸 재료이고 rendered DOM은 브라우저가 CSS와 자바스크립트를 처리한 최종 구조입니다. 모바일 렌더링 문제를 볼 때는 둘을 비교해 제목, 첫 문단, 목차, 표의 텍스트, 이미지 src와 alt, 내부 링크 목적지가 어느 단계에서 사라지거나 추가되는지 확인합니다. 개발자 도구에서 요소가 보인다는 사실만으로 원본에 있었다고 가정하지 않고, 페이지 소스와 Elements 결과를 각각 저장합니다.

Search Console URL 검사에서 라이브 테스트와 색인된 버전을 구분하고, 렌더링 화면과 로드된 자원을 확인합니다. Googlebot이 CSS·자바스크립트·이미지를 가져갈 수 없는 robots 규칙, 외부 자원 오류, 자바스크립트 예외가 있으면 사용자 브라우저와 다른 결과가 남을 수 있습니다. 화면 캡처뿐 아니라 렌더링된 HTML에서 핵심 문장과 실제 a 링크가 존재하는지 검색합니다. 접힌 메뉴 안 링크도 클릭 이벤트의 데이터 문자열이 아니라 크롤링 가능한 앵커로 남는 편이 안전합니다.

본문을 동의, 위치 권한, 로그인 성공, 사용자 클릭 뒤에만 요청하지 않습니다. 모바일에서 요소를 시각적으로 접는 것과 DOM에서 완전히 제거하는 것은 다릅니다. 데스크톱·모바일에 서로 다른 본문을 중복 생성하는 테마라면 숨김 규칙이 뒤바뀌지 않았는지 확인합니다. Googlebot 전용 경량 페이지를 제공해 점수만 개선하는 방식은 사용자와 다른 콘텐츠를 제공할 위험이 있으므로, 사용자와 검색 시스템 모두에게 같은 읽을 수 있는 본문을 제공하는 방향으로 복구합니다.

모바일 표·메뉴·긴 요소의 기능을 검사합니다

성능 감사가 통과해도 360픽셀 화면에서 표, 긴 URL, 고정 폭 이미지, 동영상 iframe이 컨테이너를 밀어 가로 스크롤을 만들 수 있습니다. 넓은 표를 통째로 이미지로 바꾸면 검색 가능한 텍스트와 접근성을 잃습니다. 중요 열을 줄이고 모바일 요약을 제공하거나, 표 자체에 명확한 가로 스크롤 영역을 제공해 페이지 전체 폭이 늘어나지 않게 합니다. 긴 링크 텍스트와 연속 문자열의 줄바꿈도 확인합니다.

햄버거 메뉴, 목차, 공유 버튼, 이미지 확대, 동의 배너의 닫기 버튼을 실제 터치로 검사합니다. 탭 영역이 지나치게 작거나 고정 헤더에 가려지고, 첫 탭 뒤 메인 스레드가 멈추며, 키보드 포커스가 사라지는 문제는 단순 로드 점수로 드러나지 않을 수 있습니다. 화면 확대, 방향 전환, 뒤로 가기 후에도 읽던 위치와 기능이 유지되는지 봅니다. 실제 공개 URL은 Blogger 편집기 미리보기와 자원·광고 조건이 다를 수 있으므로 공개본을 최종 기준으로 삼습니다.

저사양 모바일과 느린 연결도 표본에 넣습니다. 개발자 컴퓨터에서 메뉴가 즉시 열려도 실제 방문자의 CPU에서는 서드파티 실행이 입력을 오래 막을 수 있습니다. 네트워크 제한만으로 CPU 병목을 완전히 재현할 수 없으므로 기기 에뮬레이션과 실제 기기 테스트를 보완적으로 사용합니다. 기능 검사 결과를 LCP·INP·CLS 표와 분리해 기록하면 점수가 양호하지만 사용이 불가능한 회귀를 놓치지 않습니다.

변경을 격리하고 중단선에 따라 롤백합니다

수정 전에는 Blogger 테마 XML, 게시물 HTML, 이미지 원본, 광고 및 위젯 설정을 백업하고 파일명·내보낸 시각·적용 범위를 기록합니다. 문제 URL과 정상 URL에서 동일한 실험실 조건, 화면 캡처, 요청 워터폴, 렌더링 DOM, 주요 기능 결과를 기준선으로 남깁니다. 전체 사이트에 영향을 주는 테마 변경은 대표 게시물 몇 개에서 예상 효과와 부작용을 먼저 확인한 뒤 확대합니다.

한 번에 이미지 형식, 폰트, 광고 위치, 스크립트 순서를 모두 바꾸면 어떤 변경이 효과나 고장을 만들었는지 알 수 없습니다. 먼저 가장 큰 원인 후보 하나를 고르고 같은 조건으로 재측정합니다. 이미지 크기 변경 뒤에는 선명도·비율·alt·요청 URL을, 스크립트 제거 뒤에는 메뉴·댓글·분석·광고를, CSS 변경 뒤에는 여러 화면 폭과 렌더링 DOM을 읽습니다. 변동이 큰 랩 값은 여러 번 실행해 지속적인 차이인지 확인합니다.

중단선은 배포 전에 정합니다. 핵심 본문 또는 내부 링크가 렌더링 결과에서 사라짐, 대표 이미지 정보가 읽히지 않음, 메뉴나 동의 제어가 작동하지 않음, 광고가 본문을 덮음, 분석 이벤트가 중복 또는 누락됨이 발견되면 점수 상승 여부와 관계없이 롤백합니다. 되돌린 뒤에는 백업이 실제 공개본에 반영됐는지 다시 읽어야 합니다. “복원 버튼을 눌렀다”와 “사용자 화면이 복원됐다”는 같은 완료 증거가 아닙니다.

readback과 장기 관찰로 복구를 종료합니다

readback은 저장한 설정을 다시 열어 의도한 값인지 확인하고, 공개 URL을 새 세션에서 불러와 최종 HTML과 화면을 재검사하는 절차입니다. 캐시된 관리자 화면만 보지 말고 시크릿 브라우저, 모바일 폭, 느린 네트워크에서 확인합니다. 대표 이미지 요청 크기와 시작 시각, 렌더링된 본문·링크·alt, 메뉴와 광고 동작, 레이아웃 이동을 기준선과 같은 항목으로 대조합니다. Google 도구의 라이브 렌더링에서도 핵심 텍스트와 자원 차단 여부를 다시 봅니다.

기술 복구는 랩 재현, 실제 모바일 기능, 렌더링 DOM, 네트워크 요청으로 비교적 빠르게 판정할 수 있습니다. 현장 데이터는 새 방문 표본이 누적되고 URL 그룹 보고서가 갱신돼야 하므로 즉시 바뀌지 않을 수 있습니다. 보고서가 그대로라는 이유로 검증된 수정 위에 추가 변경을 연달아 쌓지 않습니다. 배포 시각을 표시한 추세에서 충분한 새 표본이 들어온 뒤 기기와 페이지군별 변화를 관찰합니다.

검색 클릭, 순위, 광고 수익은 기술 지표와 별도 시계열로 기록합니다. 계절성, 검색 수요, 콘텐츠 개정, 광고 단가와 배치가 동시에 영향을 줄 수 있으므로 CWV 변화 하나에 성과를 전부 귀속하지 않습니다. 종료 조건은 특정 점수 만점이 아니라 첫 답이 제때 보이고, 조작이 막히지 않으며, 읽는 중 화면이 안정적이고, Google 렌더링에도 같은 핵심 내용과 링크가 남고, 문제가 생기면 검증된 백업으로 되돌릴 수 있는 상태입니다.

발행 전 체크리스트

• 문제 URL과 같은 템플릿의 정상 URL을 같은 기기·네트워크 조건으로 비교했습니다.
• field data의 사용자 분포와 lab data의 재현 결과를 같은 의미로 혼동하지 않았습니다.
• LCP 2.5초, INP 200밀리초, CLS 0.1 기준을 75번째 백분위 목표와 함께 읽었습니다.
• Blogger 테마, 게시물 이미지, 광고, 분석, 위젯, 폰트의 비용을 출처별로 나눴습니다.
• 첫 화면 LCP 후보 이미지의 발견 시점, 전송 크기, 표시 크기, 지연 로드 여부를 확인했습니다.
• 반응형 이미지 후보와 src 폴백, width·height 또는 비율 예약, 문맥에 맞는 alt를 확인했습니다.
• 화면 상단 이미지는 무차별 lazy loading 대상에서 제외하고 화면 밖 자산만 선택적으로 미뤘습니다.
• 광고 슬롯, 폰트 교체, 배너, 관련 글 위젯이 만드는 레이아웃 이동을 각각 재현했습니다.
• 원본 HTML과 rendered DOM, 일반 모바일 브라우저와 Googlebot 렌더링을 대조했습니다.
• 테마와 게시물 원본을 백업하고 한 번에 하나의 변경만 적용했습니다.
• 본문·링크·메뉴·광고·측정 기능 중 하나라도 깨지면 되돌리는 중단선을 적용했습니다.
• 롤백 또는 배포 뒤 공개 URL readback을 수행하고 현장 보고서의 후속 관찰을 분리했습니다.
• Core Web Vitals 통과를 검색 순위나 수익 보장으로 표현하지 않았습니다.

Related Posts