기록
실제로 겪은 기술적 사건을 글로 풀어 둔 것입니다. 현재 73편이고, 두 프로젝트를 운영하면서 계속 늘어납니다.
- 전문 용어만 있고 사람들이 실제로 쓰는 말이 없었다 홈페이지에 'AEO'는 있는데 'AI 상위노출'은 한 글자도 없었다. 검색창에 그 말을 치는 사람에게는 이 사이트가 후보로도 안 잡히고 있었다 — 전문 용어와 구어를 같은 층에 놓기까지의 기록이다.
- 빙은 짧다고, Ahrefs는 길다고 — 두 도구가 반대로 말할 때 meta description 을 늘렸더니 다음 감사에서 정반대 지적을 받았다. 빙은 짧다고, Ahrefs는 길다고 — 어느 쪽이 맞았는지, 그리고 두 기준을 동시에 만족시킨 방법을 실제 사례로 정리했다.
- 운영 DB는 30일 뒤 지운다 — 리포트를 얼려야 하는 이유 월간 데이터 리포트를 만들려고 보니, 지난달 데이터가 이미 일부 지워지고 있었다. 운영 DB가 마감 30일 뒤 공고 행을 지운다는 삭제 정책이 리포트 완전성을 조용히 갉아먹고 있었다는 실제 이야기다.
- 광고 코드 한 줄이 검색 제외 페이지에도 그대로 나가고 있었다 광고 스크립트를 심는 코드가 값만 채우면 전 페이지에 예외 없이 나가는 구조였다. 검색에서 제외한 페이지, 정렬이 다른 페이지, 두 번째 페이지 이후에도 광고가 그대로 붙을 뻔한 구조였다는 것을 알아챘다.
- 신청자 수 0이 '없음'이 아니라 '모름'일 때 리뷰로거의 공개 경쟁률 통계가 실제보다 낮게 나가고 있었다. 원인은 스키마 하나였다 — '신청자 없음'과 '신청자 수 모름'이 DB에서 같은 0 값으로 저장되며 평균 경쟁률 계산이 왜곡되고 있었다.
- 이미 색인된 글을 지우지 않고 성격만 바꿨다 업체를 비교하는 글의 주제가 서비스 본연의 성격과 어긋난다는 것을 뒤늦게 깨달았다. 이미 검색엔진이 확인 중인 주소를 지우기는 아까워서, 주소는 그대로 두고 글의 성격만 '추천'에서 '1인칭 기록'으로 바꿨다.
- 매번 기록을 쌓는 대신 세 값으로 압축해서 보존했다 공고 하나의 신청 현황이 시간에 따라 계속 바뀌는데, 매 수집 주기마다 행을 쌓으면 연간 백만 행이 넘어간다. 그만한 분석 가치가 없다고 판단해 처음·마지막·최댓값 세 가지로만 압축해 남기기로 했다.
- 자동 수집이 며칠째 멈춰 있었는데 아무도 몰랐다 매일 자동으로 돌아야 할 수집 작업이 특정 날짜를 마지막으로 아무도 모르게 멈춰 있었다. 새 감시 장치를 만드는 대신, 이미 쌓이는 데이터 자체를 심장 박동처럼 써서 멈춤을 감지하는 검사를 만들었다.
- 지적 여섯 건을 하나씩 확인해 보니 진짜 결함은 하나였다 색인 문제로 지적받은 여섯 가지를 실제 서버 응답으로 하나씩 직접 확인해 봤다. 다섯 건은 이미 의도한 대로 정확히 처리돼 있었고, 정말 고쳐야 할 것은 페이지 번호 2 이상인 목록 페이지 하나뿐이었다.
- '모순된 신호'라고 단정했던 내 이전 판단이 과했다 검색 제외 표시와 대표 주소 지정을 함께 쓰면 모순이라고 단정해서 적어 뒀는데, 다시 확인해 보니 규격 위반도 아니고 검색엔진이 무조건 무시하는 것도 아니었다. 스스로 낸 결론을 스스로 고쳐 쓴 기록이다.
- 의심했던 페이지는 안전했고, 진짜 물린 곳은 따로 있었다 검색 페이지가 로봇 규칙으로 막혀 있어 위험하다고 생각했는데, 실제로는 그 페이지로 가는 링크 자체가 없어 위험이 거의 없었다. 정작 모든 페이지 하단에 링크되는 다른 페이지 세 곳이 진짜 문제였다.
- 월간 리포트에 넣지 않기로 한 지표 네 가지 월간 데이터 리포트를 만들면서 넣을 수 있는데도 일부러 넣지 않은 지표가 넷 있었다. 전월 대비 증감, 일별 추이, 금액 분포, 플랫폼별 경쟁률 — 전부 겉보기엔 그럴듯하지만 실제로는 다른 것을 재는 수치였다.
- 한 페이지가 목록 구조화 데이터를 두 개나 내보내고 있었다 목록 페이지 네 곳이 같은 종류의 구조화 데이터를 두 가지 다른 방식으로 중복 선언하고 있었다. 캐러셀 확장 이후 순위가 흔들린 시점과 겹쳐, 신호가 중복되면 검색엔진이 헷갈릴 수 있다고 보고 하나로 정리했다.
- 숨긴 카드를 넣었는데 캐러셀은 왜 안 붙었나 네이버 캐러셀 대응으로 숨김 마이크로데이터를 전 페이지에 넣었는데, 실제로 캐러셀이 붙는 경쟁사 방식은 화면에 보이는 이미지 세트였다. 두 개를 착각해서 15종 페이지가 여전히 빠져 있었다는 것을 뒤늦게 확인했다.
- 존재하지 않는 페이지 번호를 404로 막지 않은 이유 목록의 페이지 번호를 실제로 존재하지 않는 큰 숫자로 바꿔서 열어도 항상 200 응답에 카드 0개인 화면으로 돌아왔다. 얇은 페이지를 무한히 만드는 구멍이었는데, 이걸 404가 아니라 검색 제외로 막기로 했다.
- 로봇 규칙 세 글자가 핵심 페이지 하나를 통째로 막고 있었다 robots.txt의 Disallow 규칙 세 글자가 전혀 다른 이름의 핵심 페이지까지 함께 막고 있었다. 그 규칙은 경로 접두사로 매칭되기 때문이고, 답변엔진 12종 전부가 그 페이지를 못 읽고 있었다.
- 형제 페이지들이 다 가진 것을 전체 목록 페이지만 빠뜨렸다 지역별·분야별 목록 페이지는 전부 갖고 있는 구조화 데이터 두 가지를, 정작 가장 상위인 전체 목록 페이지 하나만 빠뜨리고 있었다. 화면에는 보이는데 코드에는 없는 이동경로였다는 것을 뒤늦게 발견했다.
- 업계 용어로만 순위를 재고 있었다 — 돈 내는 사람이 실제로 치는 말은 따로 있다 그동안 추적해 온 검색어가 전문 용어 위주로 몰려 있다는 것을 깨닫고, 실제 잠재 고객이 칠 법한 표현 36개를 새로 재봤다. 결과는 뜻밖이었다 — '어떻게 하는가'를 묻는 방법형 질문은 단 하나도 순위권에 없었다.
- 주석에 적어 둔 규칙을 코드가 강제하지 않으면 다시 깨진다 로고 파일의 배경을 완전 불투명하게 만든다고 주석에 적어 놓고, 정작 모서리를 둥글게 깎는 속성 때문에 네 귀퉁이가 투명하게 새고 있었다. 이후 이미지 생성 스크립트에 투명도를 검사하는 자동 가드를 추가했다.
- '제3자 비교 문서'라고 부른 것이 사실은 경쟁사 자기 블로그였다 업체 비교 글에서 참고할 만하다고 표시해 둔 문서를 다시 확인해 보니, 그 글을 쓴 곳이 비교 대상 업체 중 하나였고 자기 회사를 맨 첫 줄에 두고 있었다. '제3자 문서'라는 이름표부터 잘못돼 있었던 것이다.
- 우리가 남에게 요구한 규칙에 우리 사이트가 걸려 있었다 요금 안내 페이지의 질문 4개가 구조화 데이터에만 있고 화면에는 한 글자도 없었다. 우리가 발행한 글에서 '스키마에만 있고 화면에 없는 FAQ는 정책 위반'이라고 써 놓고, 정작 그 문제를 스스로 갖고 있었다.
- 쌓아 두기만 한 로그를 처음 열어 보니 전제가 틀려 있었다 방문 기록을 몇 주째 쌓아 두기만 하고 실제로 열어 본 적이 없었다. 처음 집계해 보니, 404 오류 상위 원인이 콘텐츠 수요가 아니라 자격 증명 파일을 노리는 스캔 시도였다. 심지어 그 요청들이 전부 AI 크롤러를 사칭하는 표시를 달고 있었다.
- 푸터의 메뉴 제목이 본문 소제목으로 잘못 인식되고 있었다 콘텐츠 중복을 판정하는 로직이 페이지 원본 HTML에서 소제목을 뽑는데, 푸터·헤더를 걸러내는 과정을 거치지 않고 있었다. 그 결과 푸터 메뉴 제목('AEO', 'SEO' 등)이 거의 모든 관련 후보에 사실상 와일드카드처럼 걸리고 있었다.
- 내용을 바꿔 놓고 갱신일은 그대로 뒀다 페이지에 새 섹션을 추가해 놓고, 정작 그 페이지의 사이트맵 갱신일은 예전 날짜 그대로 남겨 뒀다. 크롤러 입장에서는 '안 바뀐 페이지'로 보이는 상태였고, 스스로 정해 둔 유지 규칙을 스스로 어긴 경우였다.
- 용어 19개를 한 페이지에 묶어 두고 있었다 경쟁사는 용어 하나마다 URL이 있는데 우리는 19개 용어를 페이지 하나에 앵커 링크로만 묶어 두고 있었다. 답변엔진은 앵커를 독립 문서로 인식하지 못한다. 그중 15개를 개별 URL로 쪼개면서, 제목을 조합하는 과정에서 조사 오류까지 함께 발견했다.
- 페이지당 캐러셀 목록은 왜 하나만 남겨야 했나 네이버 캐러셀 가이드는 한 페이지에 목록 선언 1개를 권장하는데, 실측해 보니 홈은 2개·지역 상세 17장은 3개였다. 같은 타일 세트를 두 문법으로 중복 선언하고 있었기 때문에 생긴 문제였고, 검사를 새로 만들어 상한을 강제했다.
- 영어판이 늘어나자 한국어 글이 영어 페이지와 비교되고 있었다 영어판이 97장으로 늘면서 색인 대조 대상의 45%가 영어 페이지가 됐다. 언어 구분이 없던 중복 판정 로직이 한국어 질의를 영어 문서와 비교해 점수를 매기고 있어서, 비교 대상 자체를 언어별로 분리했다.
- 자동 알림보다 사람이 직접 요청하는 것이 훨씬 빨랐다 새로 만든 상업 페이지가 자동 색인 알림을 보낸 지 며칠이 지나도 검색에 안 잡히다가, 운영자가 직접 수집을 요청하자 그날 바로 자기 제목으로 검색했을 때 1위로 잡혔다. 이후 우선순위 14건을 상업적 중요도 순으로 정리해 같은 방법으로 확인 요청을 넣었다.
- 새로 만든 페이지 17개가 사이트맵에 갱신일 없이 나가고 있었다 용어사전 상세 페이지와 진단 도구 페이지 17개가 갱신일(lastmod) 없이 사이트맵에 올라가고 있었다. 배포 후 점검 단계에서 발견했고, 원고를 손으로 적지 않고 레지스트리에서 읽어오는 구조로 재발을 막았다.
- 검색 결과 브랜드 이미지를 파비콘에 맡겨 두고 있었다 조직 구조화 데이터에 로고 필드가 없어서, 답변엔진이 브랜드 이미지를 파비콘에서 추정하고 있었다. 공식 문서의 최소 크기 기준에 맞춰 512×512 정사각 로고를 별도로 새로 만들어 지정한 기록이다.
- 색인이 안 된 게 아니라 방문 자체를 안 하고 있었다 빙 웹마스터 도구로 확인하니 홈페이지가 '발견됐지만 크롤되지 않음' 상태였다. 색인 판단에서 밀린 게 아니라 그보다 한 단계 앞, 방문 자체가 안 되고 있었다는 뜻이다. 동시에 자사 로그와 빙의 주장이 서로 어긋나는 지점도 발견해 결론 없이 남겨 뒀다.
- 빙에 등록만 하면 챗봇 검색에 나온다는 것은 과장이었다 빙 색인 실측 결과 101개 URL 중 5건만 색인돼 있었고, 그마저 신규 개편 이전의 초기 페이지들뿐이었다. 그런데 같은 조사 과정에서 '빙에 없으면 챗봇 검색 인용도 막힌다'던 이전 판단이 실제로는 과장이었다는 것도 함께 정정했다.
- 브랜드명을 검색했더니 검색엔진이 마음대로 다른 말로 바꿔 검색했다 웹문서 1위까지 올라간 브랜드명을 검색창에 그대로 입력하면 검색엔진이 '다른 표기로 검색한 결과'라며 자동으로 바꿔 버렸다. 순위를 아무리 올려도 이 단계에서 걸러지면 결국 노출되지 않는 문제였다.
- 경쟁사가 인용된 걸 보고 세운 대응책 3개가 전부 틀렸다 백링크도 거의 없는 경쟁사 페이지가 답변엔진에 인용되는 것을 보고 대응책 세 가지를 세웠는데, 하나씩 검증하니 전부 틀린 가설이었다. 색인 문제도, 우리 정책 페이지 보강도, 영어판 우선도 아니었다 — 실제 병목은 다른 곳에 있었다.
- 순위 이력 파일이 통째로 사라졌다가 다운로드 폴더에서 돌아왔다 3주치 순위 기록이 쌓인 CSV 파일을 다시 열어 보니 오늘 치 몇 줄만 덩그러니 남아 있었다. 도구가 지운 흔적도 없었고, 결국 예전에 우연히 내려받아 둔 사본 파일 하나로 전체 이력을 복구했다.
- 검색 결과의 아이콘이 갑자기 기본 지구본으로 바뀌었다 운영자가 발견한 증상은 검색 결과의 사이트 아이콘이 며칠 전부터 기본 지구본 아이콘으로 바뀌어 있다는 것이었다. 배포 이력과는 무관했다. 서버 응답은 전부 정상이었지만, 공식 문서의 권장 크기·형식과 어긋난 지점 두 곳을 찾아 전부 없앴다.
- 설명을 아무리 잘 써도 '추천해줘'라는 질문에는 답이 안 된다 실제 사람들이 치는 말은 '추천해줘'인데, 이 질문 하나만 다루는 페이지가 없었다. 이 질문의 특이한 점은 목록을 요구한다는 것이다 — 한 회사를 아무리 잘 설명해도, 다른 후보들과 나열된 목록이 없으면 그 질문의 답이 되지 않는다.
- 제목에 회사 이름만 있고 무슨 회사인지는 없었다 페이지 74개의 제목을 전수 조사했더니 32개는 회사명만 있고 무슨 일을 하는 회사인지 알려주는 말이 없었고, 20개는 회사명 자체가 아예 없었다. 답변엔진이 어느 분류에 넣어야 할지 판단할 근거를 우리 스스로 지우고 있었다.
- '사람이 승인해야 발행된다'는 규칙에 뚫린 구멍 하나 URL은 반드시 사람이 확정해야 발행된다는 규칙을 세워 뒀는데, 실제 코드는 특정 방식으로 만들어진 slug만 검사하고 있었다. 다른 방식으로 만들어진 slug는 검사 자체를 조용히 건너뛰고 있었다.
- 같은 커밋인데 서버와 내 컴퓨터에서 글 목록 순서가 달랐다 구조화 데이터 속 글 목록에 정렬 규칙이 아예 없었다. 같은 커밋을 배포 서버와 로컬 컴퓨터에서 각각 빌드했더니 19건 중 13건의 순서가 서로 달랐다 — 화면에는 안 보이지만 이것도 빌드 결과물이었다.
- 검사 도구는 만들어 뒀는데 자동 실행 경로에는 안 걸려 있었다 깨진 참조를 잡는 무결성 검사를 만들어 관리자 화면과 발행 단계에는 걸어 뒀는데, 정작 매일 자동으로 도는 파이프라인에는 그 검사가 통째로 빠져 있었다. 실제로 문제가 생긴 뒤에야 이 구멍을 발견했다.
- 이 저장소의 하루는 한국시간인데 집계만 세계표준시로 자르고 있었다 관리자 화면 두 곳은 이미 한국시간 기준으로 하루를 나누고 있는데, 크롤러 집계 로직만 세계표준시(UTC) 자정으로 하루를 나누고 있었다. 같은 저장소 안에서 '하루'라는 말의 뜻이 두 가지로 쪼개져 있었다는 뜻이다.
- 숫자가 계속 오르는 걸 반복 측정 편차로 착각할 뻔했다 같은 기간 라벨로 세 번 측정했는데 매번 값이 커지고 있었다. 처음에는 반복 측정에서 흔히 있는 자연스러운 편차라고 여겼는데, 실제로는 집계 쿼리에 시간 범위 조건 자체가 빠져 있어서 진행 중인 하루가 계속 상한으로 잡히고 있었을 뿐이었다.
- 로컬에서 써 본 것만으로 자동화 서버의 하루 예산이 소진됐다 로컬 컴퓨터에서 개발하며 사용한 API 호출이, 자동화 서버가 써야 할 하루 호출 한도를 그대로 갉아먹고 있었다. 같은 장부 파일을 저장소에 커밋하는 구조라 환경 구분 없이 합산되고 있었기 때문이다.
- 세 용어를 거의 같은 말이라고 썼다가 정정한 이유 AEO와 GEO를 '거의 같은 말'이라고 설명한 적이 있다. 나중에 이 표현을 정정했다 — 셋은 같은 말이 아니라 색인·답변후보·재료라는 서로 다른 층위였다는 사실을 뒤늦게나마 다시 정리해서 밝혔다.
- 중복을 막으려던 장치가 개선된 결과까지 통째로 버렸다 판정 도구를 개선한 뒤 같은 답변을 다시 분석했는데, 중복 방지 장치가 '이미 등록된 답변'이라며 그 결과를 통째로 버렸다. 무엇이 새로 개선됐는지와 무관하게 재분석 자체가 계속 무의미해지고 있었다.
- 새로 나온 정답이 사람이 고친 값 위에 덮이지 않게 하는 법 자동 판정을 다시 돌려 정답이 바뀌었는데도 화면에는 예전 값이 그대로 남았다. 같은 조건이면 값을 통째로 되살리던 로직이, 갱신된 자동 판정까지 낡은 값으로 계속 되돌리고 있었다는 것이 원인이었다.
- 화면에 분명히 있는 글자인데 코드는 없다고 판정했다 화면에 브랜드 이름이 그대로 보이는데, 자동 판정 도구는 '언급 없음'으로 저장하고 있었다. 원인은 같은 글자라도 컴퓨터 내부에서 다른 방식으로 조합돼 있으면 문자열 비교가 조용히 실패한다는 것이었다.
- 수집 코드가 있어도 요청이 아예 그 코드를 지나가지 않고 있었다 배포 방식을 바로잡은 뒤에도 같은 문제가 재발했다. 관리자 페이지 요청은 기록되는데 일반 공개 페이지 요청은 기록되지 않았다. 로컬 테스트 환경은 이 문제를 감춰서 통과시키고 있었고, 실제 운영 환경에서만 드러나는 차이였다.
- 실험군을 나눌 자리를 만들었지만 나누지는 않았다 A/B 실험을 위한 필드를 콘텐츠 구조에 미리 만들어 뒀지만, 실제로 페이지를 실험군과 대조군으로 나누지는 않았다. 기준이 될 관측 데이터가 아직 없는 상태에서 나누면 그 구분 자체가 근거 없는 것이 되기 때문이다.
- 배포 방식을 다르게 알고 있었던 것 자체가 문제였다 이 사이트가 한 배포 서비스로 돌아가는 줄 알고 그 구조로 코드를 짜 왔는데, 실측해 보니 실제로는 완전히 다른 서비스로 배포되고 있었다. 그 결과 방문자 수집 코드가 있는데도 공개 페이지 요청을 한 건도 거치지 않고 있었다.
- 경쟁사 캐러셀을 복제하며 개선하지 말라는 지시를 받았다 네이버 검색결과에 카드 캐러셀을 붙이려고 경쟁사의 마크업 구조를 직접 역설계해서 원리를 파악했다. 운영자 지시는 명확했다 — 인라인 스타일까지 원본 그대로 복제하고, 절대 나아지게 손대지 말라는 것이었다.
- 메타데이터 작업 하나가 전체 카테고리 페이지를 500으로 만들었다 검색용 메타데이터를 확장하는 작업 중에 카테고리 페이지 전체가 갑자기 500 오류로 죽었다. 원인은 같은 이름의 변수 두 개가 서로를 가려 버린 것이었고, 빌드 도구는 이 문제를 전혀 잡지 못했다.
- 18단계 감사 프롬프트를 돌려보니 대부분 이미 되어 있었다 경쟁사는 검색에 바로 잡히는데 우리는 왜 안 되는지 끝까지 추적하다가 18단계짜리 감사 프롬프트를 받아 코드 전체를 전수 점검했다. 항목 대부분은 이미 구현돼 있었고, 진짜 격차는 다섯 가지뿐이라는 결론이 나왔다.
- 측정 시작 전에만 고칠 수 있는 것이 있다 답변엔진 목록에서 이름 하나를 뺐다. 나중이었다면 못 했을 결정인데, 첫 측정 칸이 채워지기 전이라 가능했다 — 측정 단위(분모)는 착수 전에만 고칠 수 있다는 원칙을 이 일을 겪으며 배우게 됐다.
- 지역 페이지로 가는 길이 푸터 하나뿐이었다 지역별 페이지가 실제로는 만들어져 있었는데, 헤더 메뉴 어디에도 그 링크가 없었다. 화면 맨 아래 푸터와 일부 타일에서만 닿을 수 있어, 페이지는 만들어 놓고도 찾아 들어가기 어려운 상태로 방치돼 있었다.
- '검색 1페이지'라고 적었는데 실제로는 그 안의 일부였다 지역별 실측 수치를 '검색 1페이지 기준'이라고 설명해 왔는데, 브라우저로 실제 화면을 직접 열어 확인해 보니 그건 1페이지 전체가 아니라 그 안의 한 영역(웹문서 영역)이었다. 수치 자체는 정확했지만 그 수치를 부르는 이름이 부정확했다.
- '검색 1페이지'라고 썼는데 실제로는 그 안의 한 구역이었다 지역 페이지 75곳에서 '검색 1페이지'라는 표현을 썼는데, 브라우저로 직접 화면을 열어 보니 우리가 잰 건 1페이지 전체가 아니라 그 안의 웹문서 영역이었다. 수치는 맞았지만 부르는 이름이 틀려 있었다.
- 열어도 안전해 보이는 페이지 15,831장을 열지 않기로 했다 구글은 중복 콘텐츠를 벌점이 아니라 URL 정규화로 처리하니 전량 차단이 과잉이라는 주장이 있었다. 실측해 보니 이 사이트에서는 전혀 성립하지 않았다 — 열어도 얻을 고유한 본문 자체가 애초에 없었다.
- 링크를 더 눈에 띄게 만들려던 수정이 327개 페이지를 깨뜨릴 뻔했다 카드에 있는 출처 표시를 더 명확한 링크로 승격하려고 했다. 그 표시가 이미 다른 링크 태그 안에 들어 있다는 것을 미리 확인하지 않았다면, 앵커 태그가 겹쳐 327개 색인 페이지의 카드 링크가 전부 깨졌을 것이다.
- 기억으로 설명한 크롤러 동작 방식이 공식 문서와 달랐다 어떤 크롤러가 학습용이고 어떤 크롤러가 실시간 답변용인지, 기억에 의존해 설명해 온 문장 여러 개가 공식 문서와 어긋나 있었다. 접근성 점검을 하다가 함께 발견해 세 개의 글을 한꺼번에 다시 썼다.
- 자동으로 만든 문장에서 조사가 이상하게 붙는 버그가 반복됐다 지역 이름 뒤에 조사를 자동으로 붙이는 코드가 '경기은', '대구은' 같은 어색한 문장을 만들고 있었다. 업종 이름을 자르는 코드도 두 글자짜리 단어에서 한 글자만 남기는 실수를 하고 있었다. 둘 다 자동 생성 텍스트에서 사람이 일일이 확인하기 전에는 못 잡는 종류의 결함이었다.
- 검색엔진이 어떤 마크업의 혜택을 없애면 그 마크업은 어떻게 하나 FAQ 구조화 데이터가 검색 결과에 특별하게 표시되던 기능을 구글이 어느 날 중단했다. 이미 넣어 둔 마크업을 지우지도 더 늘리지도 않기로 했다 — 다른 목적(AI 답변엔진용)이 남아 있었기 때문이다.
- 우리 스스로를 예시로 쓴 문장이 스스로 가르친 규칙을 어기고 있었다 AI 답변 화면을 보여주는 예시 이미지에 우리 브랜드가 자주 언급된다는 문구를 넣어 뒀다. 그런데 다른 글에서 '답변엔진은 문단 단위로 인용하기 때문에 예시 표시를 붙여도 측정된 사실처럼 읽힌다'고 가르치고 있었다 — 정확히 그 문제를 스스로 저지르고 있었다.
- 네이버에서 옳았던 판단 일곱 개가 구글에서는 전부 다르게 작동했다 네이버 기준으로 옳다고 판단해 적용해 둔 검색엔진 설정들을 구글 관점에서 하나씩 다시 대조했다. 일곱 개 항목 전부가 두 검색엔진에서 서로 다르게 작동하고 있었다는 사실이 실측으로 분명히 드러났다.
- 공고는 안 겹치는데 글이 겹쳐서 색인이 안 됐다 '서울 뷰티 체험단' 페이지가 공고 218건을 갖고도 1000위까지 전혀 안 잡혔다. 원인은 지역·분야명과 건수만 바뀌는 템플릿 문장이 250개 페이지에서 100% 동일했기 때문이었다는 것을 뒤늦게 확인했다.
- 리다이렉트되는 주소를 대표 주소로 지정해 두고 있었다 실제 서버는 슬래시가 붙은 주소로 응답하고 슬래시 없는 주소는 다른 곳으로 넘기는데, 대표 주소·사이트맵·구조화 데이터는 전부 슬래시 없는 주소를 가리키고 있었다. 검색엔진이 색인해야 할 주소가 결국 다른 곳으로 튕겨 나가는 주소였던 셈이다.
- 이미지 캐러셀에 별도 스키마는 필요 없었다 구글 검색결과 이미지 캐러셀은 구조화 데이터가 아니라 본문 이미지를 직접 색인해 붙이는 것이다. 카드에 이미지가 0장이던 상태에서 원본 썸네일을 핫링크로 연결하기까지 실제로 겪은 정규식 버그까지의 기록이다.
- 모바일 속도 66점을 99점으로 올리며 진짜 병목을 다시 찾았다 PageSpeed 모바일 성능 66점을 99점까지 올리는 과정에서, 처음 의심한 이미지 용량이 아니라 CSS 계산과 애널리틱스 스크립트가 진짜 병목이었다는 것을 로컬 진단 도구로 다시 하나씩 확인하게 됐다.
- AI 크롤러가 실제로 오는지 처음으로 숫자를 봤다 AI 크롤러 허용 여부를 코드로만 설정해 두고 실제로 오는지는 확인한 적이 없었다. 인프라 제공업체의 봇 관리 화면을 처음 열어 보니 답변엔진의 검색 소스로 쓰이는 크롤러가 하루 100건 넘게 다녀가고 있었다.
- 신조어 브랜드명이 검색에 안 뜨는 이유는 형태소였다 영문 'reviewloger'는 40여 페이지가 노출되는데 한글 '리뷰로거'는 0건이었다. 색인 문제가 아니라 신조어가 흔한 단어 '리뷰'로 쪼개져 신호가 희석되는 문제였다 — h1과 alternateName으로 대응했다.
- 색인은 됐는데 검색에 안 잡힌 이유는 문구 하나였다 리뷰로거 홈이 구글에는 색인됐는데 네이버 '체험단 사이트' 검색엔 전혀 안 잡혔다. 원인은 색인이 아니라 그 문구 자체가 title·본문 어디에도 없었다는 것이었다. 산문 섹션에 그 문구를 넣자 그제서야 잡히기 시작했다.
- 순위를 확인하되 조작하지 않는 선을 어디에 그었나 네이버 검색 API로 순위 추적 스크립트를 만들면서, 확인은 자동화하되 반복 자동검색·자기 결과 클릭 자동화는 처음부터 만들지 않기로 정했다. 확인과 조작은 완전히 다른 일이라고 판단했기 때문이다.