우리 사이트를 고치며 얻은 SEO 교훈

며칠 동안 검색 엔진처럼 우리 사이트를 읽어 보았고, 고칠 가치가 있는 여섯 가지를 찾았습니다. 모든 페이지에 FAQ 블록이 두 개씩 선언되어 있었고, Google은 장식용 배경 글로우를 우리 썸네일로 쓰고 있었으며, 일부 템플릿 페이지는 답하지 않는 검색어로 순위에 올라 있었습니다. 사이트의 새 섹션은 스테이징에서 우리 자신의 엣지에 막혀 있었습니다. 어느 것도 극적인 문제는 아니었습니다. 다만 조용히 노출을 깎아 먹고 있었습니다.

한 단락으로 보는 사이트 구조

mythex.ai는 빌드 시점에 미리 렌더링(프리렌더)하는 단일 페이지 앱입니다. 스크립트가 모든 경로를 순회하며 각 경로에 대한 정적 HTML 파일을 쓰고, 페이지의 제목, 설명, 구조화된 데이터(검색 엔진에 페이지가 무엇인지 알려 주는 JSON-LD 블록, 구조화된 데이터란 무엇인가 참고)를 주입합니다. 아래 내용 대부분은 크롤러가 실제로 읽는 HTML을 만드는 이 프리렌더 단계와 관련이 있습니다.

1. 모든 페이지가 자신을 FAQ 페이지라고 주장하고 있었습니다

증상. 우리 HTML 템플릿에는 사이트 전체에 적용되는 FAQPage 블록이 있었고, 그 URL은 /faq를 가리키고 있었습니다. 프리렌더는 각 페이지 고유의 FAQPage를 그 위에 추가했습니다. 그래서 사이트의 모든 페이지에는 FAQPage가 두 개씩 들어 있었고, 개인정보 처리방침 페이지는 Google에게 자신이 FAQ 페이지라고 말하고 있었습니다.

왜 중요한가. Google은 페이지당 FAQPage가 최대 하나이기를 기대합니다. 다른 곳을 가리키는 두 번째 FAQPage는 무시되는 정도가 아니라 페이지의 마크업 점수가 깎이는 원인이 될 수 있습니다.

수정. 전역 블록을 없앴습니다. 이제 각 페이지의 FAQ 마크업은 한 곳에서 만들어지며, 전체 질문 목록으로 만드는 /faq 자체도 포함됩니다. FAQ가 없는 페이지는 아무것도 선언하지 않습니다. 정직한 답이기 때문입니다. 그리고 어떤 페이지든 FAQPage를 두 개 이상 갖게 되면 프리렌더가 빌드를 실패시킵니다. 누군가의 기억 속에만 있는 규칙은 언젠가 깨지지만, 빌드가 강제하는 규칙은 깨지지 않습니다.

2. Google이 우리를 잘못된 이미지로 보여 주고 있었습니다

증상. 검색 결과에서 Mythex 썸네일은 공유용 카드가 아니라, 홈페이지 히어로 뒤에서 은은하게 맥동하는 글로우, 즉 장식용 배경 이미지였습니다.

원인. 어떤 이미지가 페이지를 대표하는지 Google에 알려 주지 않았기 때문에, Google이 찾은 이미지 중 하나를 골랐습니다.

수정. 같은 문제의 두 측면을 함께 해결했습니다.

페이지의 이미지를 명시하기. 홈페이지에는 primaryImageOfPage가 공유용 카드를 가리키는 WebPage 노드가 생겼습니다. 프리렌더된 모든 페이지의 구조화된 데이터에는 각자의 이미지(페이지 공유 이미지 또는 기본 이미지)가 들어갑니다.
장식 요소 숨기기. 배경 이미지는 robots.txt에서 차단하고, noindex, noimageindex 헤더로 제공합니다. 그래서 이미지 검색이나 썸네일에 나타나지 않습니다.

3. 검색 엔진은 우리 로고만 알고 있었습니다

우리의 Organization 마크업에는 이름, 로고, 소셜 링크 몇 개만 있었습니다. 브랜딩 정보뿐이었죠. 검색 엔진은 회사의 지식 패널을 등록 정보 같은 사실로 구성하므로, 사업자 등록증에 있는 정보를 추가했습니다. 법인명, 설립일, 설립자, 등록 주소입니다. 전화번호는 의도적으로 빼두었습니다.

4. 템플릿 페이지가 잘못된 질문에 답하고 있었습니다

증상. Search Console에서 노출은 있지만 클릭이 없는 템플릿 페이지가 세 개 있었습니다. 한 페이지는 “content strategist portfolio”와 그 변형 검색어에, 다른 페이지는 “best italian restaurant website design”에, 또 다른 페이지는 “agile board” 관련 검색어 묶음에 순위가 걸려 있었습니다. 검색어의 절반 정도에는 “free”가 들어 있었습니다. 순위는 20위 중반에서 50위 사이였습니다.

원인. 각 페이지는 사람들이 묻는 질문과 다른 질문에 답하고 있었습니다. 이탈리안 레스토랑의 좋은 웹사이트 디자인이 어떤 모습인지 보고 싶은 사람이 제품을 파는 빌더 페이지에 도착했던 것입니다.

수정. 세 페이지 모두 제품이 아니라 검색을 위해 쓴 섹션을 추가했습니다. 사람들이 입력하는 표현으로 된 제목과 설명을 넣었고, 이미 내보내던 마크업과 어울리는 FAQ도 보강했습니다.

같은 커밋에서 더 조용한 문제도 고쳤습니다. “관련 템플릿” 블록은 카테고리에서 처음 네 개의 템플릿을 가져왔기 때문에, 모든 포트폴리오 템플릿이 같은 네 개의 포트폴리오를 가리켰고 나머지 템플릿에는 내부 링크가 전혀 없었습니다. 이를 하위 카테고리 순서의 링 구조로 바꿔서, 모든 템플릿 페이지가 정확히 네 개의 링크를 들어오고 네 개를 나가도록 했습니다. 또 프리렌더된 HTML에 이 링크들을 직접 출력하도록 했습니다. 이전에는 링크가 자바스크립트가 실행된 뒤에만 존재했는데, 크롤러는 그것을 실행하지 않을 수도 있습니다.

5. 새 페이지가 배포되는 순간 Bing에 알리기

Google은 IndexNow를 무시합니다. IndexNow는 URL이 바뀌었을 때 검색 엔진에 알리는 프로토콜입니다. Bing, Yandex, Seznam은 이를 사용하며, Bing의 색인은 ChatGPT 검색이 읽는 대상입니다. AI 앱 빌더를 AI 어시스턴트가 찾지 못한다면 그것은 특별한 종류의 실패입니다.

가장 쉬운 방법은 배포할 때마다 사이트맵 전체를 제출하는 것인데, 이는 키가 제한에 걸리는 방식이고, 대부분의 배포는 검색 엔진이 신경 쓰는 것을 바꾸지 않습니다. 그래서 스크립트는 지금 서비스 중인 사이트맵과 방금 빌드한 사이트맵을 비교해 차이만 제출합니다.

이 방식을 작동하게 한 세부 사항은 두 가지입니다.

배포 전에 스냅샷을 찍으세요. 기준선은 새 빌드가 공개되기 전에 캡처해야 합니다. 배포 후에는 “라이브” 사이트맵이 이미 새 버전이므로 모든 차이가 비어 버립니다.
당분간은 새 페이지만. 우리 사이트맵에는 lastmod 날짜가 없으므로, 스크립트는 새 페이지는 알리지만 수정된 페이지는 알리지 않습니다. 모든 URL에 빌드 날짜를 찍으면 배포할 때마다 사이트 전체가 변경된 것으로 표시되는데, 바로 우리가 피하려던 스팸입니다.

프로덕션 배포에서만 실행되며, 빌드를 절대 실패시키지 않습니다. 이 단계에 이르면 사이트는 이미 공개된 상태이고, 검색 엔진 알림 하나 때문에 배포를 빨간불로 만들 가치는 없기 때문입니다.

6. 우리 엣지가 “찾을 수 없음”이라고 답하고 있었습니다

/ai 페이지를 출시했을 때(모든 종류의 비즈니스를 위한 랜딩 페이지에서 자세히 다룹니다), 정적 호스트는 제대로 제공하고 있는데도 스테이징에서는 모든 /ai 페이지가 “Not found”로 표시되었습니다.

마케팅 호스트 앞단의 서비스는 허용 목록에 있는 경로만 전달하고, 나머지는 바로 404를 반환합니다. /ai는 새 경로였고 목록에 없었습니다. 그래서 /ai와 /ai/*를 추가했고, 이 경로들이 통과하는지 확인하는 테스트도 넣었습니다. 작은 버그였지만, 누구도 눈치채지 못한 채 새 섹션을 크롤러에게 보이지 않게 만드는 종류의 버그입니다.

우리가 얻은 교훈

크롤러가 읽는 HTML을 읽으세요. 이 문제들 대부분은 브라우저에서는 보이지 않고 프리렌더된 파일에서는 명백했습니다.
SEO 규칙을 빌드 검사로 바꾸세요. “페이지당 FAQPage는 하나”라는 규칙은 이제 기억에 의존하지 않고 강제됩니다.
검색 엔진에 무엇을 뜻하는지 분명히 말하세요. 어떤 이미지나 사실이 나를 대표하는지 알려 주지 않으면, 검색 엔진이 추측합니다.
Search Console은 사람들이 어떤 질문을 했는지 알려 줍니다. 클릭 없이 노출만 있다면, 보통 페이지가 다른 질문에 답하고 있다는 뜻입니다.
모든 것이 아니라 차이만 제출하세요. 바뀐 것만 알리면 속도 제한 안에 머물 수 있습니다.

직접 만든 사이트에 같은 작업을 하고 싶다면, AI로 만든 웹사이트의 SEO 및 Google Search Console 설정하기 가이드가 기본을 다룹니다.