33장. 블로그 리라이트와 확장 기준: 고칠 글, 유지할 글, 보류할 글을 나누는 법

블로그 리라이트는 오래된 글을 전부 다시 쓰는 작업이 아닙니다. 먼저 Search Console에서 페이지별 노출·클릭·검색어를 확인하고, 실제 본문에서 정보의 정확성과 검색 의도를 점검한 뒤 유지, 부분 수정, 전면 리라이트, 통합, 삭제·비공개, 별도 글 확장 중 하나를 고르는 작업입니다. 이미 성과가 안정적이고 정보가 맞는 글은 크게 건드리지 않는 것이 답일 수 있습니다.

가장 먼저 고칠 글은 문장이 마음에 들지 않는 글이 아니라, 노출이라는 기회가 있는데 클릭이나 문제 해결이 막힌 글, 그리고 정책·가격·신청 조건처럼 틀리면 독자에게 피해를 줄 수 있는 글입니다. 반응이 전혀 없는 글은 무조건 삭제하지 말고 색인 상태, 검색 수요, 다른 글과의 중복, 내부링크 역할을 확인한 뒤 결정하세요.

리라이트 첫 화면 답

같은 길이의 두 기간을 정해 Search Console 페이지 데이터를 봅니다.
검색어와 현재 글의 답이 같은지 직접 읽습니다.
정확성 문제가 있으면 성과와 무관하게 즉시 고칩니다.
한 URL에 한 가지 조치만 정하고 수정 전 상태를 기록합니다.
수정 뒤 재크롤링과 데이터 축적 시간을 두고 다시 비교합니다.

리라이트, 통합, 삭제, 유지, 확장은 서로 다른 작업입니다

리라이트는 기존 URL이 해결하려는 중심 질문은 유지하면서 답의 정확도와 구조를 개선하는 일입니다. 제목을 검색어와 맞추고, 첫 문단에 조건부 답을 주고, 오래된 절차와 출처를 갱신하는 작업이 여기에 해당합니다. URL이 이미 적절한 검색어로 노출되고 있다면 중심 주제를 다른 것으로 바꾸기보다 현재 약속을 더 잘 지키는 편이 안전합니다.

통합은 같은 의도를 가진 여러 URL을 하나의 완전한 문서로 합치는 일입니다. ‘앱 로그인 안 됨’, ‘앱 접속 오류’, ‘앱 로그인 실패’가 사실상 같은 상황과 같은 해결 순서를 반복한다면 세 글을 각각 늘리는 것보다 원인별 분기를 갖춘 한 글이 낫습니다. 통합 후에는 남길 대표 URL과 사라질 URL의 처리, 내부링크 수정까지 한 작업으로 봐야 합니다.

비슷한 문서가 있다는 사실 자체를 자동 페널티로 해석하지는 마세요. Google은 흔한 중복 URL을 묶어 대표 페이지를 선택할 수 있지만, 운영자에게는 어느 URL의 성과를 봐야 하는지 흐려지고 링크 신호와 크롤링이 분산되는 비용이 남습니다. 따라서 통합 근거는 문장 유사도 점수가 아니라 같은 대상·준비물·완료 상태를 가진 URL이 실제로 같은 검색어에서 경쟁하는지입니다. 반대로 공통 약관이나 연락처처럼 반복될 수밖에 없는 블록은 핵심 답이 고유하다면 삭제 이유가 아닙니다.

삭제나 비공개는 정보가 위험하거나, 다른 글과 완전히 중복되고, 독립 가치와 유입·링크 역할도 없을 때 검토합니다. 단지 최근 조회수가 0이라는 이유만으로 삭제하지 않습니다. 계절 글은 비수기일 수 있고, 새 글은 평가할 데이터가 부족할 수 있으며, 허브 글은 직접 유입보다 사이트 탐색을 돕고 있을 수 있습니다.

유지는 방치가 아닙니다. 검색 의도를 잘 해결하고 성과가 안정적이며 정보가 최신인 글은 제목과 본문을 대규모로 바꾸지 않고 깨진 링크, 공식 정보의 변경, 모바일 화면을 정기 확인합니다. 확장은 기존 글을 길게 만드는 일이 아니라 별도의 준비물과 성공 상태를 가진 하위 질문을 새 URL로 만드는 일입니다.

선택	판단 신호	핵심 작업
유지	의도 일치, 성과 안정, 정보 최신	변경 최소화, 정기 검증
부분 수정	노출은 있으나 제목·첫 답·일부 정보 부족	병목 한 가지 수정
전면 리라이트	의도는 유효하나 구조·정확성 전반이 약함	같은 질문을 더 완전하게 해결
통합	같은 검색 의도의 얇은 URL이 경쟁	대표 URL 선정, 내용·링크 정리
삭제·비공개	위험·중복·무가치, 대체 문서 존재	유입·링크·대체 경로 확인 후 처리
확장	독립된 후속 검색어와 다른 성공 상태	새 글 작성 후 양방향 내부링크

Search Console은 이 순서로 확인해야 해석이 엉키지 않습니다

Google Search Console 실적 보고서 안내에 따르면 검색 실적에서 클릭, 노출, 클릭률, 평균 게재순위와 검색어·페이지 등의 기준을 확인할 수 있습니다. 이 숫자는 검색 결과에서 일어난 일을 보여 주며 애드센스 수입이나 페이지 안의 행동을 직접 설명하지는 않습니다. 먼저 검색 진입의 병목을 찾고, 사이트 내부 데이터는 별도로 해석하세요.

1단계: 비교 기간과 검색 유형을 고정합니다

최근 28일과 직전 28일처럼 길이가 같은 기간을 비교합니다. 요일 구성이 다르거나 명절·신청 마감·계절 수요가 끼면 숫자가 크게 달라질 수 있으므로 작업표에 사건을 적습니다. 웹 검색과 이미지 검색 데이터를 섞지 말고, 국가나 기기 필터를 적용했다면 두 기간에 같은 조건을 유지합니다.

2단계: 페이지에서 시작해 검색어로 내려갑니다

사이트 전체 합계만 보면 상위 URL 한두 개의 변동이 모든 문제처럼 보일 수 있습니다. 페이지 탭에서 노출 또는 클릭 변화가 큰 URL을 고른 뒤 그 URL에 페이지 필터를 적용하고 검색어를 봅니다. 현재 제목과 본문이 실제로 노출되는 검색어에 답하는지 확인하세요. 예상했던 키워드가 아니라 다른 질문에서 노출된다면 무작정 키워드를 추가하기보다 글의 원래 역할과 검색 결과의 기대를 다시 판단합니다.

3단계: 노출, 클릭, CTR, 평균 게재순위를 함께 봅니다

노출이 늘고 클릭이 유지되면 더 넓고 낮은 순위의 검색어에 표시되면서 CTR이 낮아질 수 있습니다. 이때 CTR 하락만 보고 제목이 실패했다고 단정하면 안 됩니다. 노출과 평균 게재순위가 비슷한데 클릭만 줄었다면 제목과 검색 결과의 약속을 우선 확인합니다. 노출 자체가 크게 줄었다면 계절 수요, 색인, 경쟁 결과, 오래된 정보, 사이트 기술 변경을 먼저 살펴봅니다.

4단계: URL 검사와 실제 공개 화면을 확인합니다

성과 데이터가 없거나 갑자기 사라진 URL은 URL 검사 도구 안내에 따라 Google이 알고 있는 색인 상태와 라이브 페이지의 접근 가능성을 확인할 수 있습니다. 다만 색인 가능하다는 결과가 상위 노출을 보장하는 것은 아닙니다. 시크릿 창과 모바일에서 최종 URL, 제목, 본문, canonical 설정, noindex 여부, 리디렉션과 서버 오류도 직접 확인해야 합니다.

5단계: 수정 전 기준선을 저장합니다

URL, 비교 기간, 상위 검색어, 노출, 클릭, CTR, 평균 게재순위, 현재 제목, 수정 이유를 기록합니다. 한 번에 제목·본문·URL·내부링크를 모두 바꾸면 어떤 변화가 영향을 줬는지 해석하기 어렵습니다. 안전이나 정확성 문제가 아니라면 가장 유력한 병목부터 바꾸고 재확인 날짜를 정합니다.

데이터 신호별로 수정 범위를 결정합니다

노출은 충분하지만 클릭이 약한 경우

검색어, 제목, 첫 답의 범위가 같은지 봅니다. ‘자동차 검사’처럼 넓은 제목인데 실제 노출은 ‘자동차 검사 예약 준비물’에서 발생한다면 대상과 해결 범위를 제목에 정확히 표현할 수 있습니다. 연도는 실제로 해마다 달라지는 내용을 확인했을 때만 붙이고, ‘무조건’, ‘필독’, ‘안 보면 손해’ 같은 과장은 제거합니다. 제목을 바꿨다면 본문 첫 문단도 같은 약속을 즉시 이행해야 합니다.

노출과 클릭은 있는데 답이 낡은 경우

성과와 관계없이 정확성을 먼저 고칩니다. 지원금 대상, 세금 기준, 앱 메뉴, 다운로드 경로, 상품 가격처럼 바뀌는 정보는 공식 원문을 다시 확인하고 적용 시점과 예외를 표시합니다. ‘최신’이라는 단어만 추가하지 말고 무엇을 언제 확인했고 무엇이 달라졌는지 작업 기록에 남깁니다. 금융·건강·법률·공공정책처럼 오류 비용이 큰 글은 근거를 확보할 수 없으면 보류 또는 비공개를 검토합니다.

노출은 적지만 검색어가 정확한 경우

수요가 작은 구체적 질문이거나 아직 데이터가 쌓이지 않은 글일 수 있습니다. 발행 직후라면 성급히 리라이트하지 말고 색인과 내부 탐색을 확인합니다. 질문이 사이트 주제에 맞고 답이 완결되어 있다면 유지하면서 관련 허브에서 자연스럽게 연결할 수 있습니다. 작은 수요라고 해서 가치가 없는 것은 아니며, 적은 표본의 RPM 급등을 확장 근거로 과대평가해서도 안 됩니다.

원하지 않은 검색어에서만 노출되는 경우

한 글에 여러 주제가 섞였거나 제목이 모호할 가능성이 있습니다. 현재 URL이 어떤 질문을 책임질지 한 문장으로 다시 적고, 관련 없는 구간을 삭제하거나 독립 질문으로 분리합니다. 그러나 이미 유입되는 검색어를 보고 글을 전혀 다른 주제로 바꾸면 기존 독자와 내부링크의 기대를 깨뜨릴 수 있습니다. 새 의도가 명확히 다르면 새 글이 낫습니다.

첫 문단부터 발행 품질로 리라이트하는 순서

좋은 첫 문단은 결론을 미끼처럼 숨기지 않습니다. 누가 어떤 조건에서 무엇을 먼저 해야 하는지 두세 문장 안에 답하고, 이어서 확인할 기준을 예고합니다. 예를 들어 신청 글이라면 대상 여부, 공식 신청 경로, 준비물을 먼저 제시하고 배경 설명은 뒤로 보냅니다. 오류 글이라면 데이터 손실이나 결제 위험을 먼저 경고하고 가장 안전하고 쉬운 점검부터 안내합니다.

질문 한 줄: 이 URL을 찾은 독자가 끝내려는 일을 한 문장으로 적습니다.
성공 상태: 조회 결과 확인, 설치 완료, 후보 제외처럼 눈에 보이는 끝을 정합니다.
조건부 답: 대상·예외·위험을 포함해 첫 화면에 결론을 씁니다.
정상 경로: 준비물, 공식 경로, 단계, 결과 확인을 순서대로 둡니다.
실패 분기: 자격 없음, 메뉴 없음, 오류 코드 등 멈추는 지점별 대안을 씁니다.
근거와 시점: 주장 가까이에 1차 출처를 연결하고 확인 날짜를 남깁니다.
다음 질문: 현재 답을 완결한 뒤에만 실제 후속 글을 연결합니다.

Google의 유용하고 신뢰할 수 있는 사용자 중심 콘텐츠 만들기 안내는 콘텐츠가 방문자에게 만족스러운 경험을 주는지, 명확한 출처와 전문성의 근거가 있는지 스스로 질문하도록 권합니다. 리라이트의 목표도 검색엔진만을 위한 분량 추가가 아니라 독자가 원래 목적을 달성하도록 빈칸을 메우는 데 둬야 합니다.

통합할 때는 대표 URL과 겹치지 않는 답을 먼저 정합니다

두 글이 같은 단어를 쓴다고 반드시 통합하는 것은 아닙니다. ‘여행자보험 비교’와 ‘여행자보험 청구 서류’는 대상 시점과 성공 상태가 달라 분리할 가치가 있습니다. 반면 제목만 다르고 대상, 준비물, 해결 순서가 같은 글은 통합 후보입니다. Search Console에서 두 URL이 같은 검색어에 번갈아 노출되는지, 본문의 핵심 구간이 반복되는지, 한 문서로 읽을 때 더 완전해지는지 확인하세요.

대표 URL은 현재 유입, 외부·내부링크, 주소의 명확성, 정보 완성도를 함께 보고 고릅니다. 좋은 문단과 고유 사례를 대표 글로 옮긴 뒤 중복을 제거하고 소제목 순서를 다시 설계합니다. 내부링크와 사이트맵을 대표 URL 기준으로 수정하고, 이전 URL을 처리할 수 있는 환경이라면 내용상 가장 가까운 대표 URL로 영구 리디렉션을 검토합니다. 서로 무관한 삭제 URL을 모두 홈으로 보내는 방식은 독자에게도 도움이 되지 않습니다.

URL을 바꾸는 리라이트는 본문 수정과 다른 마이그레이션입니다. 가능하면 성과 URL을 유지하고, 변경이 불가피하면 이전→새 URL 대응표, 서버 측 영구 리디렉션, 새 URL의 자기 참조 canonical, 내부링크와 사이트맵 갱신을 한 묶음으로 처리합니다. 디자인·CMS·주소·본문을 동시에 바꾸면 하락 원인과 복구 지점을 잃으므로 단계적으로 배포하세요. 세부 절차는 Google의 URL 변경 사이트 이전 안내를 따릅니다.

삭제는 마지막 조치이며 임시 숨김과 영구 정리를 구분합니다

출처 없는 건강 효능, 사칭 다운로드, 종료된 신청을 현재 진행 중처럼 안내하는 글은 검색 성과를 기다리기보다 즉시 안전하게 수정하거나 공개를 중단해야 합니다. 반대로 단순히 조회수가 없다는 글은 삭제 전에 검색 수요와 계절성, 발행 시점, 색인 상태, 내부링크, 다른 글의 중복 여부를 확인합니다.

일시적으로 잘못된 정보를 숨겨야 하는 경우와 URL을 영구 폐기하는 경우는 다릅니다. Google의 Google 검색에서 정보 삭제하기 안내는 페이지 삭제, 비밀번호 보호, noindex 등 상황에 맞는 방법을 설명합니다. Search Console 삭제 도구의 일시적 숨김만으로 원본 페이지가 영구 제거된다고 오해하지 마세요. 어떤 방식을 쓰든 사이트 메뉴, 내부링크, 사이트맵과 대체 페이지를 함께 정리해야 합니다.

확장은 반복 키워드가 아니라 독립된 작업에서 시작합니다

성과 글의 검색어 목록에서 반복되는 후속 질문을 찾되, 현재 글 안에서 짧게 답할 수 있는지 먼저 봅니다. ‘예약 가능 시간’처럼 절차의 작은 조건이면 본문에 보강하는 편이 자연스럽습니다. 반면 ‘예약 후 날짜 변경’이 별도 규정, 수수료, 취소 경로와 실패 대응을 요구한다면 독립 글로 확장할 수 있습니다.

확장 글은 원본의 문단 순서를 복사하고 키워드만 바꾸면 안 됩니다. 대상 시점, 준비물, 성공 상태가 달라야 합니다. 원본은 전체 선택 지도를 제공하고 확장 글은 한 작업을 완결합니다. 두 글은 독자가 실제로 이동할 이유가 있는 문맥에서 서로 연결하되, 현재 페이지의 핵심 답을 다른 페이지 뒤에 숨기지 않습니다.

가상 전후 사례: 자동차 검사 글을 어떻게 나누는가

가상 리라이트 전 글의 제목은 ‘자동차 검사 완벽 정리’이고, 본문에는 검사 의미, 대상, 예약, 준비물, 기간 경과 과태료, 결과 재검사까지 짧은 문단으로 섞여 있다고 가정하겠습니다. Search Console에서는 ‘자동차 검사 예약 준비물’ 노출이 많지만 클릭률이 낮고, ‘검사 기간 지남’ 검색어도 소수 들어옵니다. 첫 문단은 제도의 역사부터 시작해 예약하려는 독자가 공식 경로를 바로 찾기 어렵습니다.

리라이트 후 대표 URL은 ‘자동차 검사 예약 대상·준비물·공식 경로’에 집중합니다. 첫 화면에서 검사 대상 여부를 확인한 뒤 공식 예약 경로와 준비물을 보라고 답하고, 예약 순서·결과 확인·예약 화면 오류를 배치합니다. 제도의 긴 역사는 예약에 필요한 범위만 남기고, 공식 기관 안내의 확인일을 표시합니다. 제목과 첫 문단, 절차 구조를 바꾼 날짜와 이유도 작업표에 남깁니다.

‘검사 기간이 지났을 때’는 과태료 적용 기준, 기준일, 예외와 문의 경로가 별도로 필요하므로 공식 근거를 확보할 수 있을 때 새 글로 분리합니다. 반면 ‘예약 가능 시간’은 예약 절차 안의 짧은 조건이므로 대표 글에 둡니다. 기존에 ‘자동차 검사 예약 방법’이라는 얇은 중복 글이 있다면 고유 정보와 유입을 확인한 뒤 대표 글로 통합하고 내부링크를 정리합니다.

전후 성과는 수정 다음 날 판단하지 않습니다. 같은 길이의 비교 기간을 두고 대표 URL의 대상 검색어 노출·클릭·CTR을 확인합니다. 계절 수요와 순위 변화도 함께 보고, 새 확장 글은 별도 URL로 평가합니다. 클릭률이 올랐어도 공식 정보가 부정확하거나 독자가 예약 경로를 찾기 어려워졌다면 성공한 리라이트가 아닙니다.

또 다른 가상 사례: 앱 오류 글 세 편을 하나로 통합합니다

‘앱 로그인 안 됨’, ‘앱 접속 실패’, ‘앱 로그인 오류’ 세 글이 모두 비밀번호 재설정과 재설치만 반복한다고 가정해 보겠습니다. 각 글은 노출이 적고 같은 검색어에 교대로 표시됩니다. 이 경우 글마다 FAQ를 더 붙이기보다 ‘앱 로그인 실패 원인별 복구 순서’ 하나로 통합합니다.

통합 글은 서비스 장애 확인, 네트워크와 시간 설정, 계정 잠금, 2단계 인증, 앱 업데이트, 재설치 순서로 위험이 낮은 점검부터 배치합니다. 재설치 전에 로컬 데이터와 복구 수단을 확인하라고 경고하고 공식 상태 페이지와 고객지원 경로를 연결합니다. 운영체제별 메뉴가 크게 다르면 동일 글 안의 분기로 두되, 특정 오류 코드가 독립된 준비물과 긴 복구 절차를 요구하면 후속 글로 분리합니다.

수정 로그가 있어야 리라이트가 실험이 됩니다

기록 항목	작성 예시
대상과 기준선	URL, 비교 기간, 상위 검색어, 노출·클릭
문제 가설	검색어는 서류인데 첫 답에 준비물이 없음
변경 내용	제목 범위 수정, 준비물 표와 공식 링크 보강
안전 확인	모바일 표시, 링크, 출처, 광고 구분 확인
재확인	확인 날짜와 동일 길이 비교 기간

수정 뒤에는 검색엔진이 다시 크롤링하고 데이터가 쌓일 시간을 둡니다. 모든 글에 고정된 대기일을 적용하기보다 평소 노출 규모와 크롤링 빈도를 고려하세요. 데이터가 적은 글은 더 긴 관찰이 필요합니다. 정확성 문제는 관찰 기간을 이유로 방치하지 않고 즉시 고칩니다.

수정 로그에는 성공 조건뿐 아니라 복구 조건을 둡니다. 대상 검색어와 페이지 역할이 유지되면서 결함이 해소되면 채택하고, 같은 비교 조건에서 대표 검색어가 사라지거나 사용자가 완료해야 할 경로가 깨지면 변경 전 버전으로 되돌립니다. 단, 코어 업데이트·시즌 종료·서버 장애가 겹쳤다면 리라이트 하나의 효과로 귀속하지 않고 관찰을 연장합니다. 통합이나 URL 변경처럼 즉시 복구가 어려운 작업은 먼저 소수 URL에서 리디렉션·canonical·404·모바일 화면을 검증해야 합니다.

발행 전 최종 품질 검증

첫 두 문단에 대상, 조건, 결론이 있고 답을 광고나 내부링크 뒤에 숨기지 않았는가?
Search Console의 실제 검색어와 제목·소제목의 해결 범위가 일치하는가?
공식 출처가 주장 가까이에 있고 확인 날짜와 변경 가능성을 밝혔는가?
직접 하지 않은 경험, 근거 없는 순위, 수익 보장과 과장 표현이 없는가?
통합한 URL의 내부링크·사이트맵·대체 경로를 함께 정리했는가?
삭제할 글의 유입, 외부·내부링크, 계절성, 대체 페이지를 확인했는가?
확장 글이 원본과 다른 성공 상태를 갖고 있으며 문단을 복제하지 않았는가?
모바일에서 표·목록·공식 버튼과 광고가 혼동 없이 표시되는가?
수정 전 수치, 변경 이유, 재확인 날짜를 기록했는가?

리라이트의 핵심은 많이 고치는 것이 아니라 올바른 URL에 올바른 조치를 적용하는 것입니다. 정확하고 안정적인 글은 유지하고, 기회가 있지만 답이 약한 글은 리라이트하며, 같은 의도의 얇은 글은 통합합니다. 위험하고 대체 가치가 없는 글은 신중하게 정리하고, 독립된 후속 작업이 확인될 때만 확장하세요.

오늘은 기존 글 20개를 한꺼번에 다시 쓰지 말고 다섯 개만 골라 Search Console의 페이지→검색어→지표→URL 상태 순서로 확인해 보세요. 각 URL 옆에 유지·수정·통합·삭제 검토·확장 중 하나와 그 이유를 한 문장으로 적으면, 리라이트가 감각적인 대공사가 아니라 기록 가능한 운영 절차가 됩니다.

이 글의 Google 공식 링크는 2026년 7월 15일 확인했습니다. 검색 데이터와 색인 상태는 사이트마다 다르므로 실제 결정은 본인의 Search Console, 공개 페이지, 공식 원문을 함께 기준으로 하세요.

공부스닷컴