three.jsの3Dサイトでインデックス登録が通らない原因と直し方

この記事は、Webサイトを作るALcuesto（エールクエスト）が、自社サイトで実際に起きたことの記録です。three.jsで3Dにしたトップページだけ、Search Consoleの「インデックス登録をリクエスト」がエラーになりました。原因を見つけるまでにやったことと、直し方を、手順のまま書きます。

先に結論です。

• 原因は、3Dが重すぎて、Googleの側で描画が終わらなかったことでした。ページの作りが悪かったのではなく、GPUの無い環境で描けない量の3Dを置いていたのが理由です
• 見つけ方は、手元のブラウザを「GPU無し」にして、自分で開いてみることです。そこで再現すれば、原因はページの側にあります
• 直し方は、3Dを出す前に「この環境で描けるか」を確かめ、描けないときは静止画と文章のページを出すことです。相手がGoogleかどうかでは分けません

1. 何が起きたか

2026年9月20日、自社サイト（alcuesto.jp）のトップページを、three.jsの3Dにして公開しました。その日、Search Consoleでトップページを登録しようとして、次のようになりました。

やったこと	出たもの
トップページで「インデックス登録をリクエスト」	インデックス登録リクエストの送信中に問題が発生しました。しばらくしてからもう一度お試しください
トップページで「公開URLをテスト」	エラーが発生しました。問題が解消しない場合は、数時間後にもう一度お試しください
3Dを使っていない下層ページで、同じ操作	どちらも普通に通った

同じ日に、同じサイトの中で、トップだけが落ちました。以前に作った別のthree.jsのサイトでも、同じ症状が出たことがあります。

2. 最初に疑って、外れたもの

正直に書きます。最初に疑ったものは、どれも外れました。

疑ったこと	なぜ外れたか
1日の上限に達した	Search Consoleのヘルプに上限があると書かれているのは事実だが、同じ日に下層ページのリクエストは通った。上限なら下層も通らないはず
すでに登録済みだから送れない	これも、トップだけが落ちる説明にならない
Google側の一時的な不調	時間を置いても、トップだけが同じように落ち続けた
robots.txt・noindex・canonical・リダイレクト・応答速度	URL検査APIで調べたところ、取得はSUCCESSFUL、ロボットの判定はALLOWEDだった。どれも正常だった

上限について、Search Consoleのヘルプにはこう書かれています（Search Console ヘルプ「URL 検査ツール」）。

送信できるインデックス登録リクエストの数には、1 日あたりの上限が設定されています。

上限は本当にあります。ただ、今回の症状はこれではありませんでした。「同じ日に、同じサイトの中で、あるページは通り、あるページは通らない」なら、上限やGoogle側の不調ではなく、そのページ自体を疑うことになります。

もうひとつ、同じヘルプページに、今回の答えにつながる記述がありました。

インデックス登録エラーをすばやく検出する簡易チェックをパスしたページは、インデックス登録キューに送信されます。ライブテストでインデックス登録不可と判断された場合は、インデックス登録をリクエストできません。

つまり、リクエストの前にGoogleがページを見に行き、そこで引っかかると、リクエストそのものが送れません。「公開URLをテスト」も同時に落ちていたことと、つじつまが合います。エラーの文面は「しばらくしてからもう一度」ですが、待っても直らない場合は、ページの側を疑ったほうが早いです。

3. 再現のしかた：手元のブラウザをGoogleの側に近づける

ここからが、この記事の中心です。Googleがどういう環境でページを描いているかは、外からは見えません。なので、手元のChromeを「GPUが無い状態」にして、自分で開いてみました。

使ったのはpuppeteerです。Chromeを次の起動オプションで立ち上げると、2つの環境を作れます。

作りたい環境	Chromeの起動オプション
GPUが無く、CPUだけで描く（ソフトウェア描画）	--use-angle=swiftshader --enable-unsafe-swiftshader --disable-gpu
WebGLがそもそも使えない	--disable-3d-apis --disable-gpu

この2つで開いてみたところ、次のことが分かりました。すべて、自社サイトを2026年9月20日に手元で測った結果です。

WebGLが使えない環境：JavaScriptが止まる

ブラウザのエラーに、次の例外が出ました。

Error: THREE.WebGLRenderer: Error creating WebGL context.

この例外でJavaScriptが止まり、読み込み中の表示が出たまま、60秒たっても先に進みませんでした。画面には、壊れかけの状態だけが残ります。

ソフトウェア描画の環境：WebGLは「使える」判定になる

こちらは、もっと分かりにくい壊れ方でした。ソフトウェア描画では、WebGLは「使える」と判定されます。描画装置の名前を聞くと、GPUの名前ではなくSwiftShader（Chromeに入っている、CPUで描くための仕組み）が返ってきます。

つまり「WebGLが使えるか」だけを確かめる作りだと、この環境は素通りします。そして、約57万ポリゴンの3DをCPUで描こうとして、次のようになりました。

測ったもの	ソフトウェア描画	ふつうのGPUあり
ページの読み込みが終わるまで	25.2秒	18.1秒
1秒あたりに進むコマ数	2コマ	30コマ

（2026年9月20日に、自社サイトの修正前の版を手元で測った結果。コマ数は requestAnimationFrame が1秒間に何回呼ばれたかを数えた値）

1秒に2コマでは、動かすことも、読み込みを終わらせることもできません。Search Consoleの「公開URLをテスト」が時間切れになっていたのは、この状態だったと考えています。

もうひとつ見つかったこと：文章が読まれていなかった

ついでに分かったことがあります。ページの説明文が hidden 属性の付いた要素の中にありました。hidden の中身は画面に描かれないので、3Dが動かない環境では、読めるものがほとんど残りません。3Dの中で読める文章が、3Dが動かない相手には届いていませんでした。

4. 原因

Google 検索セントラルには、WebGLについてこう書かれています（Google 検索セントラル「Fix Search-related JavaScript problems」、最終更新 2025年12月18日）。

if you use WebGL to render photo effects in the browser, feature detection shows that Googlebot doesn't support WebGL

日本語版の同じ箇所は「ブラウザでフォト エフェクトをレンダリングするのに WebGL を使用している場合、機能検出により、Googlebot では WebGL がサポートされていないことがわかります」です（日本語版）。

ここで、正直に書いておきたいことがあります。公式は「WebGLに対応していない」と書いていますが、私が手元で再現したときは、「WebGLは使えるが、GPUが無いので重すぎる」状態でも、同じように表示が終わりませんでした。Googleの描画環境の中身は外からは見えないので、どちらだったのかは分かりません。

ただ、どちらであっても、やることは同じです。GPUのある前提で作った3Dを、そうでない相手に出さないようにすれば、両方とも直ります。

5. 直し方

同じページの中で、Googleはこう指示しています。

Ensure that your application uses feature detection for all critical APIs that it needs and provide a fallback behavior or polyfill where applicable.

私の訳では「アプリケーションが必要とするすべての重要なAPIについて、機能検出を使い、可能な場合はフォールバックの動作かポリフィルを用意してください」です。この「機能検出」を、次の形で入れました。

手順1：3Dを出してよい環境かを、最初に確かめる

ページのいちばん上に、次のスクリプトを置きます。3Dの本体より先に動かすため、外部ファイルではなくHTMLに直接書きます。

(function () {
  var ok = false, soft = false;
  try {
    var c = document.createElement("canvas");
    var gl = c.getContext("webgl2") || c.getContext("webgl");
    ok = !!gl;
    if (gl) {
      var di = gl.getExtension("WEBGL_debug_renderer_info");
      var rn = di ? String(gl.getParameter(di.UNMASKED_RENDERER_WEBGL) || "") : "";
      soft = /swiftshader|llvmpipe|softpipe|software|basic render/i.test(rn);
    }
  } catch (e) {}
  if (!ok || soft) document.documentElement.classList.add("no-webgl");
})();

確かめているのは2つです。

• WebGLが取れるか。getContext("webgl2") も getContext("webgl") も取れなければ、3Dは出しません
• 描いているのがGPUか、CPUか。描画装置の名前に swiftshader・llvmpipe などが入っていたら、CPUで描く環境なので、3Dは出しません

補足です。WebGLには failIfMajorPerformanceCaveat: true という指定があり、性能の低い環境でWebGLの取得を失敗させられることになっています。ただ、今回の環境では、これを付けてもSwiftShaderを見分けられませんでした（2026年9月20日に自社で確認）。描画装置の名前を見るほうが確実でした。

手順2：3Dの本体を、通ったときだけ呼ぶ

3Dのコード全体を関数に包み、判定を通ったときだけ呼びます。こうしないと、判定より先に three.js の読み込みが走ってしまいます。

function main() {
  /* ここに three.js のコードをすべて入れる */
}

if (!document.documentElement.classList.contains("no-webgl")) main();

手順3：3Dを出さないときに見せるものを作る

3Dを出さないときは、no-webgl が付いた状態のCSSで、次のものを見せます。

• 3Dの代わりになる静止画
• 3Dの中で読めるのと同じ内容の文章
• 各ページへのリンク

ここが大事なところです。代わりに見せる中身は、3Dの中で見られる内容と同じにします。相手によって見せるものを変えると、クローキング（検索エンジンと人に違うものを見せること）になります。だから、判定は「この環境で3Dが描けるか」という機能と性能だけで行い、User-Agentで相手がGoogleかどうかを見て分けることはしません。

あわせて、画面に出さないけれど読ませたい文章は、hidden や display: none ではなく、次のような書き方にします。これなら画面には出ませんが、文章としては残ります。

.s-sr {
  position: absolute;
  width: 1px; height: 1px;
  margin: -1px; padding: 0;
  overflow: hidden;
  clip: rect(0 0 0 0);
  clip-path: inset(50%);
  border: 0;
}

手順4：読み込み表示は、必ず時間切れで消す

「読み込み中…」の表示は、3Dの準備が終わらなくても、時間が来たら消すようにします。準備の完了を待つ作りだと、重い環境で永遠に残ります。

setTimeout(hideLoad, 8000);

6. 直した結果

直す前と直した後を、同じ手元の環境で測りました（2026年9月20日、自社サイトで測った結果）。

測った条件	直す前	直した後
ソフトウェア描画：読み込みが終わるまで	25.2秒	4.7秒
ソフトウェア描画：1秒あたりのコマ数	2コマ	62コマ
ソフトウェア描画：読み込み表示が消えるまで	7.6秒（時間切れで消していた）	0.1秒
WebGLが使えない環境：読み込み表示が消えるまで	60秒たっても消えない	0.1秒
ふつうのGPUあり：表示	どちらも今までどおり3Dが出る（変化なし）

そしてSearch Consoleでは、直したあと、次のようになりました。

• 「公開URLをテスト」が通りました。テスト結果のHTMLを見ると、1行目が <html lang="ja" class="js no-webgl"> になっていました。Googleの側でも、3Dを出さない判定が働いたということです
• 続けてインデックス登録のリクエストも通りました

この no-webgl が付いていたことが、決め手でした。推測ではなく、Googleが実際に見た結果として確認できます。

7. three.jsのサイトを作るときの事前チェック表

確かめること	確かめ方	どうなっていればよいか
WebGLが使えない環境で開いたとき	Chromeを --disable-3d-apis --disable-gpu で起動して開く	例外で止まらず、静止画と文章が出る
GPUが無い環境で開いたとき	Chromeを --use-angle=swiftshader --enable-unsafe-swiftshader --disable-gpu で起動して開く	3Dを起動せず、数秒で表示が終わる
3Dが出ないときに読める文章	その状態で、画面に出ている文字を数える	ページの中身が伝わる量がある
文章の隠し方	hidden や display: none を使っていないか見る	画面外に置く書き方にしてある
読み込み表示	重い環境で開いて放置する	時間切れで必ず消える
出し分けの基準	判定のコードを読む	機能と性能だけで判定し、User-Agentでは分けていない
代わりに見せる中身	3Dの中の文章と読み比べる	同じ内容になっている

まとめ

• 同じ日に、同じサイトで、あるページだけリクエストが通らないなら、上限やGoogle側の不調ではなく、そのページを疑う。
• 原因は手元で再現できる。ChromeをGPU無しで起動して開けば、3Dが止まるか、重すぎて終わらないかが分かる。
• 直し方は、3Dを出す前に描けるかを確かめ、描けないときは静止画と同じ内容の文章を出すこと。判定は機能と性能で行い、相手がGoogleかどうかでは分けない。

この記事で使った出どころ

公式のページは、すべて2026年9月20日に開いて確認しました。

公式

• Fix Search-related JavaScript problems（Google 検索セントラル・英語版、最終更新 2025-12-18）／日本語版（最終更新 2025-12-18）
• URL 検査ツール（Search Console ヘルプ）

自社で測ったこと

• 自社サイト（alcuesto.jp）のトップページを、修正前の版と修正後の版で、ソフトウェア描画・WebGLなし・GPUありの3つの環境で開いたときの、読み込みが終わるまでの時間、1秒あたりのコマ数、読み込み表示が消えるまでの時間（2026年9月20日、puppeteerで測定）
• Search Consoleの「公開URLをテスト」の結果と、そのHTMLの1行目（2026年9月20日）

WebGLそのものについては「そもそもWebGLって何？ブラウザだけで3Dが動く仕組みとthree.js・WebGPUとの違い」に書きました。3Dを軽くする話は「3Dサイトに最適⁉ 「転送は軽いのにGPUでは重い」を解決するKTX2の話」に書きました。GPUそのものについては「そもそもGPUって何？わかると「スマホで軽いサイト」が作れるようになる話」にあります。