이 절차로 완료되는 일
이 워크플로는 기존 공개 페이지를 추측으로 다시 쓰지 않고 개선하려는 콘텐츠 담당자, SEO 담당자, 개발자를 위한 것입니다. 20~45분 안에 하나의 검색 의도, 근거에 기반한 짧은 수정 목록, 각 수정의 담당자, 공개 후 재감사 방법을 담은 페이지별 개선 브리프를 만들 수 있습니다.
이것은 URL 하나를 위한 온페이지 SEO 체크리스트이며, 사이트 전체 기술 크롤링을 대신하지 않습니다. 페이지의 주제 신호, 콘텐츠와 링크, 의미 있는 이미지의 맥락, 구조화 데이터, 크롤링 상태를 확인한 다음 명확성, 정확성, 접근성, 중요한 크롤링 경로에 영향을 주는 항목을 고칩니다.
필요한 것은 공개된 URL과 핵심 검색어 하나입니다. 페이지가 실제로 답할 수 있다면 가까운 표현을 최대 네 개 더할 수 있습니다. 완료의 기준은 점수가 오르는 일이 아닙니다. 제목, 헤딩, 본문, 링크, 이미지, 구조화 데이터, 크롤링 신호가 검색자의 문제에 대해 일관된 설명을 하는 상태입니다.
Auspia의 온페이지 SEO 감사는 렌더링된 페이지와 HTML에서 확인할 수 있는 근거를 살펴봅니다. 약한 주제 신호와 기술적 누락을 찾는 데는 유용하지만, 순위, 백링크 권위, SERP 경쟁, 색인 여부, 방문 후 행동을 예측하거나 설명하지는 않습니다.
좋은 온페이지 검토는 분명한 페이지 근거를 작은 개선 브리프와 공개 페이지 검증 절차로 바꿉니다.
감사 전에 페이지 하나와 역할 하나를 정한다
목적이 분명한 페이지에서 시작하세요. 제품 기능 페이지, 서비스 페이지, 튜토리얼, 카테고리 페이지, 오래된 글 모두 대상이 될 수 있습니다. 하나의 검색어로 답하기 어려운 홈페이지나 넓은 허브 페이지는 처음 감사할 URL로 피하는 편이 좋습니다.
도구를 열기 전에 다음 문장을 평이한 언어로 써 보세요.
이 페이지는 [핵심 표현]을 검색하는 [대상 독자]가 [구체적 문제]를 해결하거나 판단하도록 돕는다.
예를 들어 "온페이지 SEO 감사"를 목표로 한 페이지는 공개 URL의 메타데이터, 콘텐츠 구조, 스키마, 링크, 크롤링 신호를 무료로 확인한다고 약속할 수 있습니다. 반면 "SEO 감사", "기술 SEO", "SEO 도구", "웹사이트 최적화"를 한 페이지에서 모두 노리면 감사할 만한 초점이 없습니다. 보고서가 이를 약한 커버리지로 표시할 수 있지만, 근본 문제는 브리프입니다.
입력값 | 좋은 시작점 | 품질 확인 | 불분명할 때 |
|---|---|---|---|
페이지 URL | 한 페이지의 정규 공개 버전 | 로그인이나 미리보기 토큰 없이 열림 | 사용자와 크롤러가 도달해야 할 URL을 쓰고 리디렉션을 먼저 해결한다 |
핵심 키워드 | 페이지의 중심 역할을 말하는 한 표현 | 독자가 해당 페이지에서 답을 기대함 | 표현을 좁히거나 더 잘 맞는 페이지를 고른다 |
보조 키워드 | 가까운 동의어 또는 하위 주제, 최대 네 개 | 같은 구조에서 자연스럽게 다룰 수 있음 | 관련 없는 단어는 새 섹션을 만들지 말고 제거한다 |
페이지 목표 | 정보 제공, 비교, 전환, 가입 또는 문제 해결 | CTA가 검색 의도와 맞음 | 메타데이터보다 먼저 페이지 브리프를 다시 쓴다 |
이 준비는 키워드가 한 번 덜 나왔다는 이유만으로 결함으로 판단하는 흔한 실수를 막습니다. 다른 의도를 나타내는 표현은 별도 페이지, 별도 목적의 섹션, 또는 사용하지 않는 선택이 필요합니다.
검사기를 실행하기 전에 페이지 브리프를 정하세요. 보고서는 근거를 보여 주지만 URL이 맡아야 할 검색 문제를 정하지는 못합니다.
소수의 관련 키워드로 감사를 실행한다
도구를 열어 공개 URL을 붙여 넣고 핵심 표현과 실제로 관련된 표현만 입력합니다. 도구는 쉼표로 구분한 최대 다섯 개의 키워드를 받습니다. 감사를 실행한 뒤 페이지 상태가 최신일 때 보고서 URL, 내보내기 파일 또는 메모를 작업 관리 도구에 저장하세요.
기대하는 결과는 주제 신호, 키워드 커버리지, 콘텐츠와 링크, 이미지, 스키마와 소셜 메타데이터, 크롤링 또는 기술 상태로 정리된 페이지 단위 보고서입니다. 보고서가 의도한 URL과 표현을 참조하는지 확인하는 것이 품질 검사입니다.
페이지가 리디렉션되거나 오류를 반환하거나 비인증 방문자에게 다른 콘텐츠를 보인다면 여기서 멈추세요. 수정하고 싶은 페이지를 감사한 것이 아닙니다. 시크릿 창에서 공개 URL을 시험하고, 깨진 리디렉션을 고치거나 정규 도착지를 선택하거나 공개 후 다시 감사하는 것이 복구 방법입니다. 비밀번호가 걸린 미리보기를 공개 페이지 대신 사용하지 마세요.
감사는 공개 URL과 소수의 키워드에서 시작해 페이지 수준의 콘텐츠 및 기술 근거를 살핍니다.
보고서를 할 일 목록이 아니라 근거로 읽는다
감사 점수는 간단한 요약일 뿐 순위 확률이 아닙니다. 카테고리마다 보고서를 읽으며 더 좁은 질문을 하세요. 가져온 페이지는 무엇을 보여 주는가? 그 근거가 페이지 역할을 뒷받침하는가?
확인 영역 | 답할 질문 | 먼저 고칠 가치가 큰 경우 | 서두르지 말 것 |
|---|---|---|---|
주제 신호 | 제목, 설명, URL, 헤딩, 본문이 페이지 주제와 맞는가 | 첫 화면이나 주 헤딩만으로 목적이 불분명함 | 모든 요소에 정확히 같은 키워드를 반복한다 |
콘텐츠와 링크 | 페이지가 문제에 답하고 다음에 읽을 곳으로 이끄는가 | 중요한 질문이 빠졌거나 유용한 페이지가 숨겨짐 | 수만 늘리는 일반적 앵커 텍스트의 내부 링크를 추가한다 |
이미지와 이해 | 독자가 alt 텍스트를 포함해 보조 시각 자료를 이해하는가 | 중요한 제품 이미지나 도표에 맥락이 없음 | 장식 이미지 alt에 키워드를 나열한다 |
스키마와 소셜 메타데이터 | 구조화 데이터가 보이는 콘텐츠를 설명하는가 | 기존 마크업이 무효, 불일치 또는 불완전함 | 본문에 없는 FAQ, 리뷰, Product 마크업을 추가한다 |
크롤링과 기술 상태 | 크롤러가 우선 페이지에 닿고 canonical과 robots를 해석하는가 | canonical, robots, HTTPS, 사이트맵 근거가 의도와 충돌함 | 확인하지 못한 신호를 색인 문제의 증거로 여긴다 |
보고서는 확인할 수 없는 신호를 추측하지 않고 그 사실을 알려야 합니다. 이 구분을 브리프에도 남기세요. "가져온 HTML에서 찾지 못함"은 수정 후보이지 "Google이 이 페이지를 크롤링할 수 없음"과 같은 뜻은 아닙니다.
보고서의 발견 사항은 순서대로 다룹니다. 근거를 기록하고, 공개 페이지에서 확인하고, 가장 작은 안전한 수정을 한 뒤 릴리스를 시험합니다.
점수의 세부 사항보다 페이지의 줄거리를 먼저 고친다
많은 페이지에서 먼저 효과를 내는 수정은 편집상의 수정입니다. 약속과 답을 일치시키세요. title 태그, 주 헤딩, 도입 단락, 주요 CTA, 첫 두 개의 하위 헤딩을 차례로 읽습니다. 처음 방문한 사람이 보충 설명 없이 이 페이지가 무엇을 돕는지 말할 수 있어야 합니다.
- "더 나은 마케팅 성과" 같은 모호한 제목을 대상과 문제를 말하는 제목으로 바꿉니다.
- 도입문이 답, 범위의 경계, 다음 행동을 알려 주도록 다시 씁니다.
- 중요한 하위 주제를 긴 문단에 묻어두지 말고 설명적인 헤딩 아래로 옮깁니다.
- 페이지가 잠깐만 언급하는 표현은 감사 키워드에서 뺍니다.
기대 결과는 표현을 기계적으로 동일하게 만들지 않으면서 같은 의도를 말하는 페이지 구조와 메타데이터입니다. 제목, H1, 첫 100~150단어, CTA만 읽어도 모두 같은 방문자 문제를 가리켜야 합니다. 페이지와 무관한 동료에게 문제를 말해 달라고 해 보세요. 답이 다르면 여전히 주제 문제가 있습니다.
복구 방법은 전체 페이지를 다시 쓰지 않는 것입니다. 처음 쓴 역할 문장으로 돌아가 현재 URL이 맡을 한 가지 역할을 고르고, 눈에 잘 보이는 요소부터 고치세요. 독립 페이지가 필요한 보조 의도에는 별도 브리프를 만듭니다.
콘텐츠 수정과 구현 수정을 나눈다
페이지의 줄거리가 분명해진 뒤에는 남은 발견 사항을 담당자별로 나눕니다. 이렇게 하면 보이는 페이지에 마크업이 설명할 사실이 있는지 확인하기 전에 SEO 팀이 개발 팀에 스키마 추가를 요청하는 실수를 피할 수 있습니다.
담당자 | 보고서에서 할 일 | 완료의 정의 |
|---|---|---|
콘텐츠 또는 SEO 담당자 | 제목과 설명, 헤딩, 본문 커버리지, 내부 링크 맥락, 의미 있는 이미지 alt 텍스트 | 수정 문구가 선택한 의도에 답하고 모든 주장을 페이지에서 뒷받침할 수 있음 |
개발자 | canonical, robots 지시문, HTTPS, 스키마 유효성, 렌더링 또는 크롤링 관련 근거 | 구현이 공개 페이지와 일치하고 운영 환경에서 시험됨 |
공동 검토자 | 소셜 메타데이터, 제품 사실, 법적 주장, 전환 문구, 릴리스 노트 | 미리보기가 공개 페이지와 일치하고 수정이 모순된 약속을 만들지 않음 |
구조화 데이터는 빈약한 콘텐츠를 채우는 수단이 아니라 설명 계층으로 다루세요. 보고서가 스키마 문제를 보이면 먼저 대응하는 가시적 근거를 확인합니다. Product 유형에는 제품 사실이 필요하고 FAQ 마크업에는 실제로 표시되는 질문과 답이 필요합니다. 근거가 없으면 페이지를 개선하거나 부적절한 마크업을 제거하세요. 검사 통과만을 위한 콘텐츠를 만들지 마세요.
발견 사항을 다섯 항목의 개선 브리프로 바꾼다
긴 보고서는 작은 작업까지 모두 긴급해 보이게 합니다. 첫 대응은 다섯 건으로 제한하고, 각각에 이유, 담당자, 검증 방법을 붙이세요.
우선순위 | 발견 사항 | 제안 수정 | 담당자 | 공개 후 확인 |
|---|---|---|---|---|
1 | H1이 페이지의 핵심 문제를 말하지 않음 | H1과 도입의 답을 다시 쓴다 | 콘텐츠 | 보이는 페이지를 읽고 감사를 다시 실행한다 |
2 | canonical이 오래된 URL을 가리킴 | canonical을 우선 공개 URL로 업데이트한다 | 개발 | 렌더링된 소스와 감사 근거를 확인한다 |
3 | 비교 도표에 alt 텍스트가 없음 | 도표의 판단 내용을 설명하는 짧은 alt를 추가한다 | 콘텐츠 | 접근성 검사와 재감사로 페이지를 확인한다 |
4 | 스키마가 더 이상 보이지 않는 사실을 설명함 | 오래된 스키마를 업데이트하거나 제거한다 | 개발 | 공개 페이지와 대조해 마크업을 검증한다 |
5 | 유용한 보조 가이드를 찾기 어려움 | 관련 판단 지점 가까이에 맥락 있는 내부 링크 하나를 더한다 | 콘텐츠 | 링크 목적지, 앵커 텍스트, 페이지 미리보기를 확인한다 |
실제 발견 사항은 페이지마다 다릅니다. 핵심은 이 페이지의 명확성, 도달성, 정확성을 얼마나 직접 개선하는지로 순위를 매기는 것입니다. 추측에 가까운 수정은 이후 백로그로 남기세요. 한 번의 릴리스에서 모든 경고 카테고리를 비울 필요는 없습니다.
안전하게 공개하고 같은 감사를 다시 실행한다
합의한 변경은 평소의 검토 절차를 거쳐 공개합니다. CMS 미리보기뿐 아니라 공개 페이지를 확인하세요. 변경이 HTML, 헤더, 구조화 데이터에 의존하면 소스 보기나 기술 검증 도구를 사용합니다.
그다음 같은 URL과 같은 키워드 집합으로 감사를 다시 실행합니다. 요약 점수만 비교하지 말고 근거를 비교하세요.
- 제목, H1, 도입문이 페이지 역할을 분명하게 전달하는가?
- canonical, robots, 스키마, 링크, 이미지 속성이 공개 버전에서 업데이트되었는가?
- 다시 쓰면서 페이지에 필요한 사실, 주의 사항, 전환 경로를 지우지 않았는가?
- 남은 경고는 의도적인가, 도구의 근거 범위 밖인가, 다음 개선 주기의 담당자가 정해졌는가?
완료란 공개 페이지가 승인된 브리프를 반영하고 고친 신호가 가져온 페이지의 근거에 나타나며 해결하지 않은 항목에 이유나 다음 담당자가 있는 상태입니다. 기반 페이지가 불분명한데 점수만 바뀌었다면 완료가 아닙니다.
공개 후에도 보고서를 유용하게 쓰는 법
큰 페이지 개편, 템플릿 변경, 이전, 리디자인 뒤 또는 현재 의도와 가시적 신호가 명확히 어긋난다는 보고서가 있을 때 온페이지 감사를 다시 실행하세요. 안정된 페이지는 매일 확인하기보다 정기 콘텐츠 검토에 사용합니다.
서로 다른 질문에 답하는 정보원과 함께 사용하세요. Search Console은 검색 성과와 쿼리 추세를, 기술 크롤링은 사이트 전체 구현 패턴을, SERP 조사는 페이지가 현재 검색자 기대와 맞는지를 보여 줄 수 있습니다. Auspia 감사는 하나의 공개 페이지가 접근 가능한 HTML과 콘텐츠로 실제 무엇을 말하는지에 초점을 둡니다.
자주 묻는 질문
온페이지 SEO 감사의 높은 점수가 순위를 보장하나요?
아니요. 점수는 페이지 수준 준비 신호를 요약할 뿐 순위 가능성이 아닙니다. 백링크, 경쟁, 검색 수요, 색인, 사용자 만족도, 검색 엔진 시스템은 보고서 범위 밖입니다.
키워드는 몇 개를 입력해야 하나요?
핵심 표현 하나로 시작하세요. 페이지가 정당하게 답할 이유가 있는 가까운 동의어나 하위 주제만 더합니다. 도구는 최대 다섯 개를 받지만, 입력을 늘린다고 감사의 정확도가 높아지지는 않습니다.
보고서의 모든 문제를 고쳐야 하나요?
아니요. 페이지의 명확성, 접근성, 정확성, 크롤링 가능성에 영향을 주는 근거부터 시작하세요. 의도적이거나 영향이 작은 항목은 기록된 백로그에 남깁니다. 억지 수정은 페이지를 더 나쁘게 만들 수 있습니다.
아직 공개하지 않은 페이지에도 이 감사를 쓸 수 있나요?
아니요. 이 도구는 공개 페이지 URL을 감사합니다. 인증이 필요한 페이지는 안전한 공개 버전을 만들거나 스테이징 및 공개 전 검사를 사용하세요.
저자: Julian Mercer, Auspia의 14년 경력 테크니컬 SEO 실무자. Julian은 크롤링 가능성, 구조화 데이터, 팀이 검증할 수 있는 실용적인 페이지 개선에 관해 씁니다.
