/tools/pe-ratio-calculator/ 페이지의 28일 데이터에 따르면 "forward pe calculator"가 6.7위 위치에 머물러 있었습니다. 이 페이지는 5월 13일에 개선되었습니다 — FactSet에서 가져온 새로운 Forward P/E 벤치마크, HowTo JSON-LD 스키마 (schema) 블록, 그리고 AI Overviews (AI 개요)를 돕기 위한 AI 인용 가능 답변 섹션이 추가되었습니다. 위치 6.7은 개선 작업이 목표로 했던 정확한 서브 쿼리 (sub-query)였습니다. 성공 사례에 대한 글을 200단어 정도 썼을 때, 개선 날짜별로 데이터를 분리해 보아야겠다는 생각이 들었습니다. 순위는 이미 그곳에 있었습니다. 커밋 (commit) 전부터 말입니다.

설정
이제 자동화 프로세스는 도구 라이브러리 전체에 걸쳐 41회 실행되었습니다 — 하룻밤에 페이지 하나씩, 4월 중순 이후로 하루도 빠짐없이 진행되었습니다. 이번 주 실행 내역은 P/E Ratio (5월 13일), SaaS Valuation (5월 14일), Book Value (5월 14일), Valuation Multiple (5월 15일), Burn Rate (5월 16일)를 포함합니다. 패턴은 일관적입니다: 현재 벤치마크 데이터를 가져오고, 작업 예시를 추가하며, HowTo 구조화된 데이터 (structured data)를 추가하고, 내부 링크를 연결합니다. 지난 30일 동안에만 31개의 페이지가 개선되었습니다. 제가 6주 동안 답을 찾으려 노력해 온 질문은 이 모든 것이 GSC (Google Search Console)에서 측정 가능한가 하는 점이었습니다. 이번 주에 저는 후보가 될 만한 데이터를 발견했습니다.

내가 예상한 것 vs 데이터가 보여준 것
P/E 계산기에 대한 28일 페이지 레벨 데이터는 고무적이었습니다:

쿼리 레벨 (query-level) 상세 내역을 추출했을 때, "forward pe calculator"는 6.7위 위치를 보여주었습니다 — 이는 Forward P/E 벤치마크 테이블과 전용 답변 블록을 추가함으로써 5월 13일 개선 작업이 직접적으로 목표했던 정확한 서브 쿼리였습니다. 이것은 증거처럼 보였습니다. 자동화가 Forward P/E 콘텐츠를 추가했고, Forward P/E 쿼리가 1페이지 근처에 나타났습니다. 깔끔한 인과관계였습니다. 그 후 저는 좁은 시간 범위를 설정하여 분석했습니다.

결과 #1: 순위는 개선 전부터 존재했다
개선 전 기간 (5월 6일~12일 — 5월 13일 커밋 전 전체 일주일):

"Forward pe calculator"는 개선 사항이 적용되기 전 주에 이미 4.5위였습니다. 클릭은 1회였습니다.

이미 1페이지에 있었습니다. 개선 후 기간 (5월 13일–17일):

"Forward pe calculator"는 개선 후 4.5위에서 12.0위로 떨어졌습니다. 28일간의 집계(aggregate) 데이터는 이들을 함께 평균 냈습니다. 즉, 4.5위에서의 노출(impression) 4회, 12.0위에서의 1회, 그리고 그 이전 어딘가에서 발생한 10위 근처의 노출 1회를 합산하여 6.7위라는 결과를 산출했습니다. 이는 마치 해당 변경 사항이 초래한 결과처럼 보였습니다. 하지만 그렇지 않았습니다. 제가 집계 데이터로부터 구성한 순서가 거꾸로 되어 있었던 것입니다. 이는 1주 차의 대출 상환 계산기(loan payment calculator) 사례와 동일한 함정입니다. 즉, 집계된 순위 지표(aggregate position metric)가 그럴듯한 이야기를 들려주지만, 실제로 내용을 열어보면 기초 분포(underlying distribution)가 즉각적으로 그 이야기를 부정하는 경우입니다. 당시에는 "평균 순위 9.8"이 2.5위부터 98위까지의 분포를 숨기고 있었습니다. 이번에는 "개선 후 순위 6.7"이 가장 좋은 결과가 작업보다 앞서 있었던 타임라인을 숨기고 있었습니다.

발견 사항 #2: 개선은 무언가 다른 것을 해냈다 — 단지 다를 뿐

개선 후 기간은 실제 효과를 보여줍니다. 헤드 키워드(head term)인 "Pe ratio calculator"는 60.0위에서 50.3위로 이동했습니다. 10개 순위가 상승했습니다. 표본이 작지만(각각 3회의 노출), 경쟁적인 쿼리(competitive query)에서 방향성 있는 움직임을 보였습니다. 개선 전 주에는 없었던 세 가지 쿼리가 나타났습니다: 9.0위의 "ratio calculator", 11.0위의 "price earning ratio calculator", 21.0위의 "debt to earnings ratio calculator". 순위 9.0위의 "Ratio calculator"는 주목할 만합니다. 이는 광범위하고 일반적인(generic) 쿼리이며, 섹터 벤치마크 테이블(sector benchmark table)과 구조화된 데이터(structured data)가 추가된 후 페이지가 이 쿼리와 더 강력하게 매칭된 것으로 보입니다. 노출은 1회였습니다. 조치를 취하기에는 너무 작습니다. 하지만 전주에는 없었으며, 광범위한 분류 쿼리(classification query)가 9위에 나타나는 것은 특정 롱테일(long-tail) 쿼리가 기존 순위를 유지하는 것과는 다른 결과입니다. 이번 개선은 일반적이고 관련 있는 용어들에 대해 새로운 쿼리 표면(query surface)을 만들어냈습니다.

제가 공을 돌리려 했던 특정 "forward pe calculator" 결과는 만들어내지 못했습니다. 발견 사항 #3: P/E calculator 임프레션(impressions)의 78%는 보이지 않음. 28일간의 페이지 수준(page-level) 데이터: P/E calculator에 대해 516회의 임프레션 발생. 쿼리 수준(query-level) 세부 내역: 25개 쿼리에 걸쳐 113회의 노출된(visible) 임프레션 발생. 403회의 임프레션 — 전체의 78% — 은 GSC(Google Search Console)의 개인정보 보호 임계값(privacy threshold) 미만입니다. 각각 1~2회의 임프레션을 가진 개별 쿼리들입니다. GSC는 이를 합계로 계산하며, 그것이 무엇인지 알려주지 않습니다. 이는 기여도(attribution) 문제에 있어 중요합니다. "Forward pe calculator"는 단일 주간에 4회의 임프레션을 쌓았기 때문에 노출되었습니다. 임계값 미만의 모든 것은 보이지 않습니다 — 제가 결코 볼 수 없는 쿼리에서 순위 2.0에 위치해 있을 수도 있고, 혹은 90위에 있을 수도 있습니다. 위에서 실행한 Pre/Post 분리 분석은 임계값을 초과하는 쿼리만을 보여줍니다. 임계값 미만의 403회 임프레션에는 1페이지 근처에 위치한 잠재적인 결과가 수십 개 더 포함되어 있을 수도 있고, 혹은 전혀 없을 수도 있습니다. 28일 기간에 대한 쿼리 세부 내역은 25개의 노출된 쿼리를 반환했습니다. 이 페이지는 절대 표면화되지 않는 최소 403개의 추가적인 검색 변형(search variations)과 매칭되고 있습니다. 그중 일부는 개선 작업 전에도 존재했습니다. 일부는 새로 생겼을 수도 있습니다. 저는 알 수 없습니다. 발견 사항 #4: og:title 태그가 여전히 살아있음이 확인됨. 개선 작업 후 P/E calculator의 HTML 상태를 검증하면서, 표준 og:title 카운트를 실행했습니다: $ curl -sSL -A "Googlebot/2.1" "https://valuefy.app/tools/pe-ratio-calculator/" | \ grep -cE '<meta property="og:title"' 2. 두 개의 태그가 나타났습니다. index.html에 있는 정적인 일반(generic) 태그 하나와, 렌더링된 출력물에 있는 React Helmet 태그 하나입니다. 처음 지적된 지 8주가 지났습니다. 여전히 그대로입니다. 이 문제를 다시 논쟁하지는 않겠습니다 — 5주 차에서 왜 이것이 존재하는지, 그리고 잘못된 가정이 무엇이었는지 다루었습니다. 하지만 자동화가 수행하는 모든 개선 사항 — P/E 페이지의 구조화된 데이터(structured data) 추가 및 벤치마크 업데이트를 포함하여 — 이 여전히 사이트 전체의 일반적인 제목을 첫 번째 og:title 신호로 전송하는 페이지에 적용된다는 점은 주목할 가치가 있습니다. 이에 대해 제가 할 일: 기여도를 주장하기 전에 Pre/Post 분리 분석을 실행할 것입니다.

앞으로: 주간 GSC (Google Search Console) 데이터에서 개선된 페이지가 나타날 때마다, 개선 전 (pre-improvement) 윈도우 체크를 가장 먼저 실행할 것입니다. 집계 (Aggregate) 데이터는 트렌드 관찰용이며, 좁은 윈도우 (narrow window)는 기여도 분석 (attribution)용입니다. 2주 후에 "ratio calculator"를 확인해 보세요. 개선 후 노출수 1회와 함께 순위 9.0으로 나타났습니다. 조치를 취하기에는 데이터가 너무 적지만, 만약 다음 사이클에서 지속적으로 나타난다면 이는 구조화된 데이터 (structured data) 추가가 더 넓은 분류 쿼리 (classification queries)를 포착하고 있다는 의미입니다. 그것이 바로 자동화가 구축한 것의 실제 이야기일 것입니다. 이전의 세 가지 개선 사항에 대해서도 동일한 분석을 실행하세요. 4월 배치 (batch)에는 EBITDA, ROAS, CTR, CPC, DCF, Cap Rate 및 기타 십여 개가 포함되었습니다. 그중 일부 페이지는 노출을 생성하고 있습니다. 저는 해당 페이지들의 순위가 개선 전에 잠재적 (latent)으로 존재했는지, 아니면 개선에 의해 생성되었는지 알고 싶습니다. 동일한 방법으로, 커밋 (commit) 날짜를 기준으로 Pre/Post 분리 분석을 수행하세요. 정적 (static) og:title을 수정하세요. 그것이 명확하게 무언가를 차단하고 있기 때문은 아닙니다. P/E 계산기는 그것에도 불구하고 클릭과 순위 변동을 생성하고 있으니까요. 하지만 8주는 충분히 긴 시간입니다. index.html에서 단 한 줄만 제거하면 됩니다. 불편한 교훈: 집계 (Aggregate) 시간 윈도우는 트렌드를 추적하는 데는 좋지만, 기여도 분석 (attribution)에는 좋지 않습니다. 5월 13일 Forward P/E 콘텐츠를 명시적으로 추가한 개선 이후, 28일 데이터에서 "forward pe calculator"가 순위 6.7로 나타났을 때, 제 뇌는 패턴을 완성해 버렸습니다: 개선 → 순위 상승. 시간적 중첩 (temporal overlap)이 그것을 사실처럼 느끼게 만들었습니다. 집계 데이터는 잘못된 것이 없었습니다. 28일 평균을 정확하게 보고하고 있었을 뿐입니다. 순차적 흐름을 인과관계 (causation)로 읽은 것은 바로 저였습니다. 이제 자동화가 수행하는 모든 개선 사항은 제가 그것에 대해 글을 쓰기 전에 Pre/Post 분리 분석을 통해 검증되어야 합니다. 최종 확인 단계가 아니라, 첫 번째 단계로서 말입니다. 만약 순위가 이미 그곳에 있었다면, Post 데이터는 그 순위에 관한 것이 아닙니다. 만약 커밋 이후에 순위가 깔끔하게 나타났다면, 그때는 우리가 말할 거리가 있는 것입니다. 좋은 소식: 개선이 실제로 효과를 보였습니다. "Ratio calculator"가 순위 9.0에 위치했습니다. "Pe ratio calculator"는 60위에서 50위로 이동했습니다.

이전에는 없었던 새로운 쿼리 표면 (query surface)이 나타났습니다. 이는 "자동화가 1페이지를 타격했다"는 이야기보다는 더 겸손한 이야기일지 모르지만, 사실이며 만약 이 패턴이 30페이지 이상에서 유지된다면 복리로 작용할 것입니다. 2주 후에 4월 배치 (batch)에 대한 Pre/Post 분석을 가지고 돌아오겠습니다. 순위가 잠재되어 있었고 자동화가 이를 드러내고 있는 것인지, 아니면 개선 사항이 실제로 새로운 표면 (surface)을 만들어내고 있는 것인지에 대한 문제입니다. 이는 데이터가 답할 수 있는 질문입니다. 저는 valuefy.app에서 이러한 실험을 진행하고 있으며, 진행하면서 발견한 내용들을 기록하고 있습니다. 만약 여러분이 프로그램틱 SEO (programmatic SEO)를 구축하고 있거나, "합계는 괜찮아 보이지만 분포 (distribution)가 무언가를 숨기고 있다"는 동일한 문제와 싸우고 있다면, 의견을 나누고 싶습니다. 댓글을 남기거나 연락해 주세요. 저는 또한 기업을 위한 AI 툴링 (AI tooling)을 구축하는 AImiten을 운영하고 있습니다. 이 사이드 프로젝트는 아이디어들이 클라이언트 작업에 적용되기 전에 스트레스 테스트 (stress-tested)를 거치는 곳입니다.