同じ不具合をなぜ片方だけ修正したのか - サイトマップのlastmodと実験中の介入
公開
この記事は2026年8月10日にIntrix Labが韓国語で公開した記事の翻訳です。
2つのサイトで同じ不具合を見つけましたが、修正したのは片方だけです。サイトマップのlastmodに、コンテンツが変更された時刻ではなく、データベースのバッチ処理が実行された時刻が入っていました。当社の企業サイトはすぐに修正し、lastmodの異なる値の数が21個から86個に増えました。一方、直接運営する皮膚科情報サイトは、修正せず、まず14日間の観測を始めました。そちらではランダム化比較実験が進行中だからです（2026-08-11時点）。
何が間違っていたのですか？
サイトマップのlastmodは、「このページが最後に変更された時刻」を伝える値です。2つのサイトとも、そこにデータベースへの書き込み時刻が入っていました。
当社の企業サイトでは、89項目に対して異なる値は31個しかなく、41項目が2026-08-06T02:13:11.569Zで、ミリ秒まで同じでした。人が41本の記事を同じミリ秒に修正することはできません。記事を一括反映した時刻が、そのまま出力されていたのです。
皮膚科情報サイトは規模が大きいため、さらに顕著でした。サイトマップの3,584件すべてが直近8日以内の値を持ち、異なる値は6個でした。内容が何も変わらなくても、内部処理がデータに触れるだけで更新時刻が書き換わる構造でした。
なぜ問題なのですか？
実際に変更されたのはごく一部でした。ある週には、17,820件中17,792件が変更なし（99.84%）だったにもかかわらず、更新時刻はすべて新しく記録されていました。
その結果、サイトマップは毎週、「3,584件すべてが過去1週間以内に修正された」と繰り返し通知します。検索エンジンは、lastmodが継続的に不正確だと判断すると、その値を全面的に無視します。シグナルを伝えるどころか、シグナルを捨てさせる状態でした。
企業サイトはなぜすぐに修正したのですか？
実験を行っていなかったからです。一括反映の時刻ではなく、実際の公開時刻を出力するように修正しました。結果は、lastmodの異なる値の数が21個 → 86個、同じ時刻を共有するページ数が60件 → 3件です。残った3件は、実際に同じ時刻に公開した記事です。
背景もあります。同時点のインデックス登録状況は、登録済み65件 / 未登録68件で、登録率48.9%でした。未登録68件のうち42件が「検出 - インデックス未登録」、つまりURLは認識されているものの、クロールさえされていない状態でした。
ただし、この不具合が原因で42件が登録されなかったとは言いません。新しいドメインのクロールバジェットや外部リンクの不足のほうが、大きく影響している可能性があります。現時点で確定しているのは、「修正できる不具合があり、それを修正した」という点までです。効果は次のインデックス登録レポートで確認する必要があります。
皮膚科情報サイトはなぜそのままにしたのですか？
そのサイトでは、病院1,991施設を4群に分けたランダム化比較実験が進行しています（2026-08-10開始、10-05終了）。実験中に別の要素を変えると、併用介入になります。
得失を考えると、割に合いません。修正によって得られるのは検索クローラーやインデックス登録に関するメリットですが、失うリスクがあるのは、AIボットの訪問数、まさにこの実験のアウトカム変数です。測定していない指標を得るために、測定している指標をリスクにさらすことになります。
バイアスが生じるわけではありません。修正は群に関係なく全ページに適用されるため、無作為割り付けによって吸収されます。問題は検出力です。「毎週修正されている」というシグナルがなくなり、クロール総量が減ると、観測数が減ります。アウトカム変数が回数である実験で観測数が減ると、検出力が下がります。
では、何を根拠に判断するのですか？
主な不明点は1つです。AIクローラーがサイトマップのlastmodを読むのか。lastmodをスケジューリングに使うと文書で明らかにしているのは検索エンジンであり、AIクローラーがそうしているかは確認されていません。
そこで、修正する代わりに、まずAIクローラーがサイトマップを実際に取得しているかを確認することにしました。また、確認を始める前に判定基準を決め、記録に残しました。結果を見てから基準を決めるのは、事後的な正当化だからです。
判定日は2026-08-25に設定しました。AIクローラーによるサイトマップへのリクエストが0件なら修正を進め、1件でもあれば10-05まで変更を凍結します。
この判断はどこまで信頼できますか？
この検証で結論が出るのは一方向だけです。「0件」はリスクがないことを意味しますが、「1件以上」は取得したという事実にすぎず、lastmodをスケジューリングに使っている証明にはなりません。そのため、1件以上の場合の対応を「追加調査」ではなく、変更の凍結と決めました。分からないままリスクを取らないという判断です。
規模も誇張しません。皮膚科情報サイトのインデックス未登録ページ数は、クリニックのURL3,584件より桁が大きい数です。その大半は、地域と施術の組み合わせで自動生成されたページであり、この不具合がインデックス未登録の主因だという根拠はありません。修正する価値のある実在の不具合だということまでが、現時点で言えるすべてです。
私たちは順位や引用、インデックス登録を保証しません。この記事が答えられるのは、2つのサイトで同じ不具合をどう異なる方法で扱い、その判断にどのような根拠があったかまでです。判定結果は、統計的に有意かどうかにかかわらず、このLabページで公開します。
よくある質問（FAQ）
Q. 自社サイトにも同じ問題があるか、どう確認すればよいですか？
サイトマップをダウンロードし、lastmodの異なる値の数を数えてください。URL数に比べて異なる値が極端に少ない場合や、複数のページが秒・ミリ秒まで同じ値を持つ場合は、バッチ処理の書き込み時刻がそのまま出力されている可能性が高いです。
Q. lastmodを完全に省略するのはどうですか？
分からない値を作るよりはよい方法です。私たちも、値が分からない項目には記載しないことを選びました。ただし、正確な値を記載できるなら、記載するほうがよいです。
Q. 実験中は何も修正してはいけないのですか？
そうではありません。判断基準は、「その修正がアウトカム変数に影響するか」です。影響しないという根拠があれば修正してもよく、根拠がなければ、根拠を得るか待つのが適切です。今回は根拠を得るほうを選びました。