SEO 업체·개발사 협업 수정 요청, 창구 지정부터 배포 후 검증까지
SEO 업체와 개발사가 협업할 때 SEO 업체는 개발사에 직접 수정을 지시하지 않습니다. 발주사 담당자 한 사람이 요청을 받아 개발사로 넘기는 방식이 안전합니다.
순서는 창구 지정, 근거 확인, 요청서 전달, 스테이징 확인, 배포 후 검증입니다. 단계마다 끝난 기준을 정하면 같은 수정이 두 번 오가는 일이 줄어듭니다.
| 단계 | 맡는 쪽 |
|---|---|
| 1. 창구 지정 | 발주사 |
| 2. 근거 확인 | SEO 업체 → 발주사 |
| 3. 요청서 전달 | 발주사 → 개발사 |
| 4. 스테이징 확인 | 개발사·SEO 업체 |
| 5. 배포 후 검증 | SEO 업체·발주사 |
SEO 업체가 개발사에 바로 요청하면 어떤 문제가 생기나요?
두 업체가 각각 발주사와 따로 계약한 경우가 많습니다. 이때 개발사 입장에서 SEO 업체의 요청은 계약 범위 밖의 지시가 됩니다.
범위와 비용, 일정을 정하는 사람이 없으면 요청은 쌓이기만 합니다. 누가 무엇을 바꿨는지도 흐려집니다.
Google의 「Do you need an SEO?」 문서에 따르면 고용한 업체가 한 행동의 최종 책임은 사이트 소유자에게 있습니다. 같은 문서는 사이트에 하는 모든 변경 내용을 공유하는지 SEO 업체에 물어보라고 권합니다.
변경 내역의 주인이 발주사라면 요청의 출입구도 발주사에 두는 편이 맞습니다.
요청 창구는 누가, 어떻게 정하나요?
창구는 발주사가 정하고 두 업체에 같은 내용으로 알립니다. 아래 네 가지를 한 번에 정합니다.
- 발주사 쪽 담당자 1명을 정하고 두 업체에 같은 날 알립니다.
- 요청을 기록할 문서 하나를 정합니다. 공유 스프레드시트나 업무 관리 도구 중 하나면 충분합니다.
- 두 업체가 서로 직접 연락할 수 있는 범위를 정합니다. 기술 질문은 허용하고, 작업 지시는 담당자를 거치게 합니다.
- Search Console 권한을 정리합니다. Google 문서는 진단 단계에서 SEO 업체에 쓰기 권한은 주지 말고 읽기 권한만 주라고 안내합니다.
끝난 기준: 두 업체가 담당자 이름과 기록 문서 위치를 회신으로 확인하면 1단계가 끝납니다.
SEO 업체 권고 가운데 무엇을 개발사로 넘기나요?
SEO 업체의 진단 결과를 그대로 개발사에 전달하지 않습니다. 담당자가 근거와 급한 정도를 먼저 거릅니다.
Google 문서는 도구나 진단 보고서의 권고를 받으면 큰 변경을 하기 전에 Google 검색 공식 안내와 대조하라고 하며, 권고의 근거로 공식 문서를 인용하는지도 물어보라고 권합니다.
실무에서는 항목마다 아래 세 가지가 있는지 확인하는 방법을 권합니다.
- 대상: 문제가 있는 주소 또는 페이지 틀(템플릿) 이름
- 근거: 공식 문서 이름이나 Search Console 보고서 이름
- 바뀌어야 할 상태: 수정 뒤 화면이나 코드가 어떻게 보여야 하는지
세 가지 중 하나라도 비어 있으면 SEO 업체에 되돌려 보충을 받습니다. 그다음 급한 정도에 따라 묶습니다.
| 구분 | 예 | 전달 시점(실무 제안) |
|---|---|---|
| 검색 노출을 막는 문제 | 실서버 페이지의 noindex 태그, 검색 로봇 접근 차단, 서버 오류 | 확인 즉시 별도 요청 |
| 일부 페이지에 영향 | 특정 템플릿의 제목 중복, 구조화 데이터(검색엔진용 정보 표기) 오류 | 다음 정기 배포에 포함 |
| 개선 권고 | 문구 조정, 이미지 설명 보강 | 월 단위로 묶어 전달 |
Google의 noindex 문서는 Search Console 페이지 색인 생성 보고서를 안내합니다. 이 보고서에서 noindex 규칙이 발견된 페이지를 볼 수 있으므로, 첫 번째 줄의 문제는 범위부터 확인합니다.
끝난 기준: 모든 항목에 대상, 근거, 바뀌어야 할 상태, 구분이 채워지면 2단계가 끝납니다.
개발사에 보내는 요청서에는 무엇을 적나요?
개발사는 SEO 용어보다 바꿀 파일과 화면을 알아야 움직입니다. 요청서는 개발자가 바로 작업 범위를 셀 수 있게 씁니다.
| 항목 | 작성 예 |
|---|---|
| 요청 번호 | SEO-07 (기록 문서 번호와 같게) |
| 대상 | 블로그 글 상세 템플릿 (해당 주소 예시 3개 첨부) |
| 현재 상태 | 페이지 머리 영역에 noindex 메타 태그가 있음 |
| 바뀌어야 할 상태 | noindex 메타 태그 삭제. 다른 태그는 그대로 유지 |
| 근거 | Google 「Block Search indexing with noindex」 문서, 페이지 색인 생성 보고서 |
| 확인 방법 | 배포 후 페이지 소스와 URL 검사 실시간 테스트로 확인 |
| 희망 배포일 | 다음 정기 배포일 |
| 회신 요청 | 같은 템플릿을 쓰는 다른 페이지 종류, 작업량, 배포 예정일 |
템플릿 하나를 고치면 여러 페이지가 함께 바뀝니다. 그래서 회신 요청 칸에서 영향을 받는 페이지 종류를 반드시 묻습니다.
예를 들어 가상의 ○○ 기업이라면 메일 본문을 아래처럼 쓸 수 있습니다.
「안녕하십니까. ○○ 기업 웹 담당자입니다. 검색 노출 관련 수정 요청 1건을 보냅니다. 요청 번호는 SEO-07이며, 블로그 글 상세 템플릿의 noindex 메타 태그 삭제 건입니다. 상세 내용은 첨부한 요청서와 같습니다. 같은 템플릿을 쓰는 페이지 종류, 예상 작업량, 배포 예정일을 회신해 주시기 바랍니다. 배포 전 시험 서버에서 SEO 업체 확인을 거친 뒤 반영하려 합니다.」
끝난 기준: 개발사가 영향 범위, 작업량, 배포 예정일을 회신하고 담당자가 기록 문서에 옮기면 3단계가 끝납니다.
배포 전 스테이징에서는 무엇을 확인하나요?
스테이징은 실서버에 반영하기 전에 변경을 시험하는 서버입니다. 이 단계에서 SEO 업체가 결과를 확인해야 배포 뒤 되돌리는 일이 줄어듭니다.
먼저 스테이징이 검색에 노출되지 않게 막혀 있는지 봅니다. Google의 robots.txt 소개 문서에 따르면 robots.txt는 페이지를 Google 검색에서 빼는 수단이 아닙니다. 다른 곳에서 링크하면 차단된 주소도 검색 결과에 나타날 수 있어, 색인을 막으려면 noindex나 비밀번호 보호를 쓰라는 것이 문서의 안내입니다.
비밀번호로 막은 스테이징은 Google 도구도 열지 못합니다. 리치 결과 테스트 도움말은 테스트 대상의 리소스가 익명 사용자에게 열려 있어야 한다고 설명하고, 공개 주소가 없을 때는 코드 입력 방식으로 구조화 데이터를 시험할 수 있다고 안내합니다.
스테이징 확인은 아래 순서로 진행합니다.
- 요청서의 바뀌어야 할 상태와 스테이징 페이지 소스를 하나씩 비교합니다.
- 구조화 데이터를 고쳤다면 해당 코드를 리치 결과 테스트의 코드 입력란에 넣어 오류를 확인합니다.
- 같은 템플릿을 쓰는 다른 페이지 종류도 한두 개씩 열어 의도하지 않은 변화가 없는지 봅니다.
- 스테이징 전용 설정이 실서버로 넘어가지 않는지 개발사에 확인을 받습니다. 대상은 비밀번호 보호, noindex 태그, 검색 로봇 차단 규칙입니다.
네 번째 항목은 배포 뒤 사이트 전체가 검색에서 빠지는 사고를 막기 위한 질문입니다. 실무에서는 요청 건마다 한 줄로 회신을 받는 방법을 권합니다.
끝난 기준: SEO 업체가 확인 결과를 기록 문서에 남기고, 발주사 담당자가 배포 승인을 개발사에 알리면 4단계가 끝납니다.
배포 뒤에는 무엇을 보고 요청을 닫나요?
요청은 배포 완료가 아니라 검증 완료로 닫습니다. 실서버 확인과 Search Console 확인을 나눠서 진행합니다.
실서버 확인
Search Console의 URL 검사 도움말에 따르면 기본 화면은 실시간 결과가 아니라 가장 최근에 색인된 버전입니다. 배포 직후에는 실시간 테스트로 지금 상태를 확인해야 합니다.
실시간 테스트를 통과해도 Google이 페이지에 접근할 수 있다는 뜻일 뿐이며, 색인 생성 요청 역시 등록을 보장하지 않습니다. 요청 횟수에는 하루 한도가 있으므로, 수정된 페이지가 많으면 사이트맵 제출을 함께 검토합니다.
noindex 문서는 규칙을 지우거나 바꾼 효과가 Google이 페이지를 다시 크롤링한 뒤에 나타난다고 설명합니다. 중요도가 낮은 페이지는 반영까지 오래 걸릴 수 있습니다.
Search Console 검증
보고서에 오른 문제를 고쳤다면 페이지 색인 생성 보고서의 수정 결과 확인 기능을 씁니다. 도움말의 내용은 아래와 같습니다.
- 문제가 있는 페이지를 모두 고친 뒤 요청합니다.
- 먼저 일부 표본 페이지를 확인하고, 이어서 문제가 알려진 주소만 다시 크롤링합니다.
- 문제가 남은 페이지가 발견되면 검증이 실패로 끝납니다.
- 검증이 성공하거나 실패할 때까지 버튼을 다시 누르지 않습니다.
- 검증은 대개 약 2주 안에 끝나지만 더 오래 걸릴 수 있습니다.
검증이 진행되는 동안 요청 상태는 검증 중으로 표시합니다. 실패하면 같은 요청 번호로 개발사에 재요청을 보내 이력이 이어지게 합니다.
끝난 기준: 보고서에 오른 문제는 검증 통과가 확인되면 요청을 닫습니다. 문구 조정처럼 보고서에 오르지 않은 요청은 실서버 확인 결과를 기록 문서에 남기면 닫습니다.
정리
수정 요청이 지연·중복되는 원인은 요청 경로와 끝난 기준이 정해지지 않은 데 있습니다. 이번 주에는 아래 순서로 시작합니다.
- 발주사 담당자 1명과 기록 문서 1개를 정한 뒤 두 업체에 같은 날 알립니다.
- SEO 업체에서 받은 권고마다 대상, 근거 문서, 바뀌어야 할 상태가 있는지 확인하고 급한 정도로 묶습니다.
- 요청서 양식의 여덟 항목을 채워 개발사에 보내고 영향 범위와 배포일 회신을 받습니다.
- 스테이징에서 SEO 업체 확인과 스테이징 전용 설정 제외 여부를 받은 뒤 배포를 승인합니다.
- 배포 뒤 URL 검사 실시간 테스트 결과와 수정 결과 확인 상태를 기록하고, 요청 종류에 맞는 기준으로 요청을 닫습니다.
참고 자료
- Do you need an SEO? (Google Search Central, 확인일 2026-10-22)
- URL Inspection tool (Search Console 도움말, 확인일 2026-10-22)
- Page indexing report (Search Console 도움말, 확인일 2026-10-22)
- Rich Results Test (Search Console 도움말, 확인일 2026-10-22)
- Block Search indexing with noindex (Google Search Central, 확인일 2026-10-22)
- Introduction to robots.txt (Google Search Central, 확인일 2026-10-22)