“SEO 좀 신경 써 주세요” 라는 요청은 대부분 아무것도 바꾸지 못한 채 사라집니다. 담당자가 게을러서가 아닙니다. 그 문장에는 시작점이 없기 때문입니다. 어느 주소를, 무엇을 근거로, 어떤 상태로 만들어야 하는지가 없으면 작업은 시작될 수 없습니다.
이 회차는 앞의 여섯 회차를 실제로 쓰는 방법입니다. 원리를 아는 목적은 직접 고치기 위해서가 아니라 고칠 수 있는 요청을 쓰기 위해서입니다.
요청서의 다섯 줄
이 중 가장 자주 빠지는 것이 ②관측과 ④판정 방법입니다. 관측이 없으면 담당자가 문제를 재현하는 데서 시간을 다 쓰고, 판정 방법이 없으면 언제 끝난 것인지 아무도 모릅니다 — 작업이 끝나도 “정말 해결된 건가요” 라는 대화가 한 번 더 붙습니다.
관측과 해석을 섞지 않습니다
요청서에서 가장 값어치 있는 부분은 본 것을 그대로 적은 문장입니다. 해석을 앞세우면 담당자는 그 해석을 검증하는 데 시간을 쓰게 되고, 해석이 틀렸을 경우 조사 방향 전체가 어긋납니다.
예를 들어 이렇게 씁니다. “/products/ 의 필터 주소들이 색인되고 있습니다”(관측) “서치콘솔 페이지 리포트에서 중복 사유가 지난달부터 늘고 있고, site: 검색에 ?sort= 가 붙은 주소가 나옵니다”(근거) “파라미터가 붙은 주소들이 파라미터 없는 주소를 대표로 가리키게 해 주세요”(원하는 상태) “배포 뒤 해당 주소들의 canonical 을 확인하고, 다음 달 리포트에서 중복 사유가 줄어드는지 봅니다”(판정).
한 요청에 한 변경
여러 건을 한 요청에 묶으면 무엇이 효과를 냈는지 알 수 없고, 문제가 생겼을 때 되돌릴 단위도 사라집니다. 다섯 가지를 한꺼번에 바꾸고 지표가 나빠지면, 원인을 찾기 위해 다섯 가지를 하나씩 되돌려 봐야 합니다.
도구가 뱉은 리포트를 그대로 전달하는 것도 같은 문제를 만듭니다. 리포트에는 우리 사이트에 해당하지 않는 항목과 우선순위가 낮은 항목이 섞여 있고, 고르는 일 자체가 마케터의 판단입니다. 그 판단을 넘기면 담당자는 대개 위에서부터 처리하게 되는데, 그것이 우리에게 중요한 순서일 이유는 없습니다.
요청 전에 스스로 확인할 것
세 가지만 확인해도 요청의 절반이 완성됩니다. URL 검사로 어느 단계에서 멈췄는지 보고(1회차), 사이트맵을 열어 그 주소가 실려 있는지 보고(3회차), 결과 화면에서 실제로 어떻게 나오는지 봅니다(2회차). 이 셋을 캡처해 붙이면, 담당자는 재현 없이 바로 원인 쪽으로 갈 수 있습니다.
요청과 배포를 하나의 흐름으로 만드는 방법은 개발 워크플로우 아카이브에 이어지고, 우리가 실제로 어떤 순서로 작업하고 무엇을 근거로 완료를 판정하는지는 작업 과정에 그대로 공개돼 있습니다.
다음 회차
마지막 회차는 이 모든 것을 매달 반복 가능한 형태로 줄입니다. 30분에 여덟 항목, 순서까지 정해 두면 점검이 습관이 됩니다.