2026-07-24 · DEVELOPMENT RECORD

서브도메인 배포와 검색 신호를 한 주소로 맞추기

주소가 바뀌면 링크만 고치면 된다고 생각하기 쉽다. 그러나 API 경로, 정적 문서, canonical, 공유 이미지, 검색 도구 확인 파일이 같은 대표 주소를 말하지 않으면 공개 서비스의 신호는 흩어진다.

작성 PPStudio 운영자게시 2026-07-24검토 2026-08-16

주소 정리와 검색 성과의 차이

대표 URL을 바꾸면서 앱과 정적 문서의 주소를 맞췄다. canonical과 사이트맵뿐 아니라 검색 도구의 확인 파일도 새 주소에서 열려야 했다. 소스에 있는 태그와 배포 서버가 내보내는 응답을 따로 확인했다.

처음에는 서브패스 배포를 지원했지만, 이후 앱을 서브도메인 루트에 두기로 했다. 이 변화는 Vite 기본 경로만 바꾸는 일이 아니라 공개 문서의 링크, API 라우트, 404, 헤더, canonical을 한꺼번에 다시 확인해야 하는 일이었다.

검색 엔진은 화면에 보이는 브랜드가 아니라 URL과 메타데이터의 일관성도 읽는다. 대표 주소가 여럿처럼 보이면 어느 페이지를 수집해야 하는지 불필요한 신호를 보내게 된다.

운영 도메인과 공유 메타데이터를 site 설정으로 모으고, 모든 공개 문서가 자기 절대 canonical을 갖게 했다. robots와 sitemap도 같은 대표 주소를 가리키고, 홈 JSON-LD에는 WebSite와 PPStudio 운영 주체를 연결했다.

카탈로그는 브라우저와 공유 캐시 정책을 분리하고, 메뉴판은 현재 페이지의 이미지 다섯 장만 낮은 우선순위로 불러오게 했다. 주소와 메타데이터를 맞추는 동안 첫 화면에서 요청하는 이미지 수도 줄였다.

Cloudflare Functions에서 Google과 네이버의 확인 문자열을 정확한 .html 경로로 200 응답하도록 만들었다. 리디렉션이 확인 파일을 가로채지 않는지도 별도 수정으로 점검했다.

social preview 메타, 구조화 데이터, favicon과 향후 앱 아이콘도 추가했다. 최종 HTTPS URL에서 루트·공개 문서·팁·이미지·404와 확인 경로를 확인하는 항목을 테스트 체크리스트에 남겼다.

새 페이지를 만들 때는 canonical, 사이트맵, 내부 링크와 구조화 데이터의 주소가 일치해야 한다. 일부 문서에 옛 주소가 남으면 링크를 따라온 방문자가 다른 배포본으로 이동할 수 있다.

확인 파일과 메타 태그가 준비돼 있어도 실제 수집 여부는 Search Console에서 별도로 봐야 한다. 이 작업에서는 URL과 배포 응답을 맞췄으며 검색 순위 변화는 측정하지 않았다.

정확한 sitemap과 canonical은 수집을 돕는 신호이지 검색 노출을 보장하는 장치는 아니다. 실제 등록, 크롤링, 리디렉션 동작은 배포된 운영 환경에서 계속 확인해야 한다.

이후 확인할 항목은 검색 도구의 수집 상태와 실제 대표 URL이다. 배포 응답이 정상이어도 검색에 반영되는 시점은 별도로 확인해야 한다.