한 페이지가 목록 구조화 데이터를 두 개나 내보내고 있었다

무엇이 중복돼 있었나

목록을 보여주는 페이지 네 곳을 확인해 보니, 같은 성격의 구조화 데이터가 두 가지 형태로 동시에 나가고 있었다. 하나는 화면 마이크로데이터로 심어 둔 이미지 캐러셀용 목록이고, 다른 하나는 별도의 JSON 형식으로 선언한 목록이었다. 한 페이지에 같은 뜻의 목록 선언이 두 개씩 있는 셈이었다.

왜 문제가 될 수 있다고 봤나

캐러셀 확장 작업을 한 이후 순위가 흔들린 시점이 있었는데, 그 흔들림이 이 중복 선언과 관련이 있을 가능성을 열어 두고 있었다. 검색엔진에게 같은 뜻의 신호를 서로 다른 형식으로 두 번 주면, 어느 쪽을 기준으로 삼을지가 우리 통제 밖의 일이 된다.

어떻게 정리했나

페이지 하나에는 목록 구조화 데이터가 하나만 있어야 한다는 원칙을 세우고, 둘 중 하나를 남기기로 했다. 남긴 쪽은 실제 이미지가 있는 캐러셀 쪽이었다 — 이미지가 없는 형식의 목록 선언은 애초에 캐러셀을 만들 수 없으니 선언만 중복시키는 것과 같았다. 이미지 없는 쪽의 사용을 여섯 개 페이지에서 제거했고, 플랫폼 전체 목록 페이지에 있던 같은 종류의 중복도 같은 이유로 걷어냈다(그 페이지의 목록 자체는 화면에 그대로 남아 있다).

검사 도구는 왜 다시 만들어야 했나

이 문제를 자동으로 잡아내는 검사를 새로 만들면서, JSON 형식만 세면 안 된다는 것을 알게 됐다 — 마이크로데이터 방식으로 나가는 목록 선언은 JSON 형식이 아니라서 그 방식만으로는 통째로 놓치게 된다. 실제로 처음 만든 감사에서 정확히 이렇게 놓쳤다. 두 형식을 함께 세도록 고친 뒤에야, 페이지당 정확히 하나씩만 있어야 한다는 규칙을 제대로 검사할 수 있었다. 대표 페이지 스무 장을 골라 검사한 결과, 수정 전에는 초과·누락이 다수였고 수정 후에는 전부 정확히 하나씩으로 통과했다.

검증 중 걸린 오탐

개발 환경에서 자동으로 붙는 디버그용 속성 때문에, 이미지의 대체 텍스트와 마이크로데이터의 이름이 일치하는지 확인하는 정규식이 스무 건 정도 잘못 걸렸다. 원본 코드를 직접 대조해 보니 실제로는 전부 일치하고 있었다 — 검사 도구 자체의 오탐이었다.