사이트맵 경로를 표준으로 맞춰 GSC 제출 오류 해결

GSC에 사이트맵 URL을 제출하려다 막혔다. 문제는 코드가 아니라 경로 자체였음.

배경 — GSC가 요구하는 건 딱 하나

Google Search Console에 사이트맵을 등록할 때 GSC는 기본적으로 /sitemap.xml 이라는 경로를 기대한다. 엄밀히는 어떤 URL이든 제출할 수 있지만, 실무에서는 표준 경로로 맞춰두는 게 훨씬 관리가 편하다. 크롤러가 robots.txt 에서 자동으로 찾아가는 경로도 /sitemap.xml 이 관례고, 다른 도구들(Bing Webmaster, 각종 SEO 감사 도구)도 이 경로를 먼저 확인한다.

문제는 formpack 프로젝트의 빌드 결과물이 /sitemap.xml 이 아닌 다른 경로로 생성되고 있었다는 것. 그 상태에서 GSC에 제출 URL을 맞추려면 매번 실제 경로를 찾아 넣어야 했고, 이건 사람이 실수할 여지가 크다. 운영 중에 경로가 바뀌기라도 하면 GSC 제출 URL을 업데이트하는 걸 깜빡하는 일도 생긴다.

결론적으로 "GSC가 기대하는 URL과 실제 파일 위치를 일치시켜야 한다"는 단순한 요건이었는데, 이걸 빌드 스크립트 레벨에서 처리하기로 했음.

작업 내용 — ops/publish.sh 에 별칭 생성 추가

변경 파일이 ops/publish.sh 하나인 걸 보면 빌드/배포 파이프라인 쪽 핀포인트 수정이다. 별도 코드 로직을 건드리지 않고 퍼블리시 단계에서 심볼릭 링크나 파일 복사로 /sitemap.xml 별칭을 만들어주는 방식.

대략 이런 패턴이다:

# 빌드 산출물 디렉터리 기준 예시
SITEMAP_SRC="./dist/sitemap/sitemap.xml"   # 실제 생성 경로
SITEMAP_ALIAS="./dist/sitemap.xml"          # GSC 제출 표준 경로

if [ -f "$SITEMAP_SRC" ]; then
  cp "$SITEMAP_SRC" "$SITEMAP_ALIAS"
  echo "[publish] sitemap alias created: $SITEMAP_ALIAS"
fi

심볼릭 링크(ln -s)를 쓸 수도 있지만, 정적 파일 호스팅 환경에 따라 심링크를 올바르게 서빙하지 못하는 케이스가 있어서 단순 복사가 더 안전한 선택이 되는 경우가 많다. 두 방식 비교:

이번엔 배포 스크립트에서 처리하는 걸 선택했다. 인프라 설정을 건드리지 않아도 되고, 코드 리뷰 이력에도 남으니까.

회고 — SEO 작업이 "운영 스크립트"로 들어오는 순간

SEO 관련 이슈는 개발팀 입장에서 미묘한 위치에 있다. 프론트엔드 코드도 아니고, 백엔드 로직도 아니고, 빌드 파이프라인도 아닌데… 결국 다 조금씩 걸쳐 있다.

이번 작업처럼 "경로 하나 맞추는 것"이 실제로는 여러 선택지를 비교하고 가장 파급 범위가 작은 지점을 찾아 수정하는 과정이었음. 팀에서 이런 류의 변경을 리뷰할 때 내가 주로 보는 포인트:

• 변경이 다른 배포 단계에 사이드이펙트를 주진 않는지
• 실패 시 사일런트하게 넘어가지 않도록 분기/로그 처리가 있는지
• 나중에 이 스크립트 보는 사람이 "왜 이게 여기 있지?" 하지 않도록 주석이 달려 있는지

특히 세 번째가 의외로 자주 빠진다. publish.sh 같은 운영 스크립트는 자주 안 열어보다 보니 맥락 없는 코드 한 줄이 나중에 "이거 지워도 되나?" 논의를 만들어낸다. SEO 목적의 별칭 생성이라는 걸 한 줄 주석으로 남겨두는 게 기술 부채 안 쌓는 방법.

GSC 제출 후 색인 반영까지는 며칠 걸리는 게 보통이라 효과 확인은 좀 기다려야 한다. 그게 SEO 작업의 특성이기도 하고.

다음은 sitemap 내 URL 구조 쪽도 점검할 차례.

🛒 이 글과 어울리는 추천 상품

• 외장SSD 쿠팡에서 보기 →
• 기계식키보드 쿠팡에서 보기 →
• 모니터암 쿠팡에서 보기 →

*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.