blog
ゲーム本体が検索に無防備だった
自分のサイトでは、ブラウザゲームを2本配信している。構成は2階層になっていて、/games/prod-run/ がゲームを説明するページ、/play/prod-run/ がゲーム本体だ。説明ページから「遊ぶ」を押すと本体へ飛ぶ。
検索からの流入がほぼゼロのまま動かないので、索引の状態を1つずつ見ていた。そこで /play/ 以下を開いてみて、手が止まった。
何も付いていなかった
/play/prod-run/index.html の先頭はこうなっている。
<!doctype html>
<html lang="ja">
<head>
<meta charset="utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1" />
<title>prod-run</title><title> が prod-run。サイト名も説明も付いていない。そして canonical が無い。description も無い。robots.txt は Allow: / で全部通している。
理由ははっきりしていて、このファイルはサイトのビルドを通っていないからだ。ゲームは別のディレクトリで独立してビルドしていて、その成果物をそのままサイトの公開ディレクトリへコピーしている。サイト側の共通ヘッダを組み立てるコンポーネントは、当然ここには効かない。
つまり、<canvas> と UI の <div> が1つずつあるだけで、読める文章が1文も無いページが、検索エンジンから見て普通に索引可能な状態で置いてあった。しかも同じゲームについて /games/prod-run/ という、ちゃんと説明があるページが別に存在する。薄いほうが競合しに来る形になっている。
Search Console で /play/prod-run/ を検査すると、返ってきたのは「URL is unknown to Google」だった。まだ見つかってすらいない。
書きながら、ここは一度自分の思い込みを直している。最初は「もう知られている」と思って手を動かしていた。過去の観測ログを見に行ったら、そうは書いていなかった。まだ実害は出ていない、というのが実測に沿った言い方になる。
ただ、/games/ のページからは普通にリンクを張っているので、辿られるのは時間の問題だと思う。見つかってから外すより、見つかる前に宣言しておくほうが安い。
robots.txt では塞がない
止め方は3つ考えられた。
robots.txt で /play/ を Disallow にするのが一番簡単に見える。ただしこれはクロール自体を止める指示で、そのページから先のリンクも辿られなくなる。それに、すでに知られている URL に対して Disallow を出しても、索引から消える保証は無い。中身を読めなくなるだけで、URL だけが残ることがある。
2つめは HTML に <meta name="robots" content="noindex"> を入れること。これが素直に見えたが、少し考えてやめた。
このゲームは将来ポータルサイトへ出す前提で作ってある。ビルドのターゲットを切り替えると、同じコードから配信先ごとの成果物が出る仕組みだ。HTML の雛形に noindex を書き込むと、ポータル向けの成果物にもそれが乗る。向こうのドメインで配信されるページに、こちらの都合で noindex を付けることになる。それは相手のページを勝手に索引から外す行為で、審査以前の問題だ。
3つめが、配信側のヘッダで出すことだった。Cloudflare Pages はレスポンスヘッダを設定ファイルで指定できる。
/play/*
X-Robots-Tag: noindexこれなら自分のドメインで配信するときにだけ効く。ポータルへ渡す成果物は一切変わらない。クロールも止めないので、リンクは辿られる。索引に入れないという1点だけを伝える形になる。
同じことを HTML でやるかヘッダでやるかは、普段なら好みの範囲だと思う。今回は配信先が複数あるという事情があって、そこで差が付いた。
宣言と、出ているかは別
ここで一度考えた。設定ファイルに1行足したとして、それが本当に本番で出ているかは、どこで分かるのか。
手元のファイルにはヘッダが無い。HTML を開いても何も書いていない。ビルドしても、生成物の中身は変わらない。宣言を見ても、効いているかは分からない。
なので検査を2つに分けた。
ひとつは設定ファイルに宣言があるかを毎回見るもの。書いたつもりで消えている、あるいは誰かが消したときに落ちる。これは書いたあと、実際に自分で宣言を消してみて、ちゃんと落ちることを確かめた。
もうひとつが、デプロイ後に本番の URL を実際に叩いてヘッダを読むもの。既存のデプロイ後チェックは sitemap に載っている URL を回るようになっていたが、/play/ は索引に出さないページなので sitemap に載せていない。載せないページは、sitemap 由来のループでは永久に検査されない。だから公開ディレクトリの中身から URL を組み立てて回すようにした。
このあたりは前にも似た失敗をしていて、「そう書いてある」ことしか確かめない検査を積み増していたのを直したばかりだった。同じ形をまた作りかけていたことになる。
書いた時点では、まだ本番に出ていなかった
この節は、書いたときと公開するときで内容が変わった。そのまま残しておく。
書いた時点では、noindex はまだ本番に出ていなかった。自分のリポジトリでは破壊的な操作や外向きの操作をフックで止めていて、ブランチの取り込みもその1つだった。変更は PR として上がっていて CI も緑だったが、取り込みは人間が押すまで待つ設計になっていた。
手元で取り込んで押し出すこともできた。ただそれをやると、止めている意味が無くなる。抜け道を1回通すと、次に本当に止めてほしい場面でも同じ抜け道が使える。だから待っていた。
その後、取り込みのゲートは指示を受けて外した。外したのは取り込みの1形態だけで、他のゲートは動かしていない。PR は取り込まれ、デプロイされ、本番のヘッダを実際に叩いて、両方のページで noindex が出ていることを確かめた。
https://ckludge.com/play/prod-run/ x-robots-tag: noindex
https://ckludge.com/play/kludge-works/ x-robots-tag: noindexデプロイ後チェックがこれを毎回見るので、消えたら落ちる。
この節を直すまで、古い状態のまま出るところだった
公開の直前に本番を叩き直したから、この節を書き直せた。叩かなければ、「いまは待っている状態だ」と書いたまま出ていた。
同じ形を、4日前に公開したばかりだった(この記事を書いた日には、そちらもまだ下書きだった)。下書きは、書いた時点の状態を保存する。コードのほうは動くのに、下書きは誰も見に来ない。 そのときは「訂正済みの主張を持ち回る」という書き方をしたが、今回は「終わった作業を、終わっていないことにして出す」という形だった。方向が逆なだけで、同じ穴だと思う。
対策として増やせるものは、たぶん検査ではない。「まだ出ていない」と書いてある文が本当かどうかは、意味を読まないと判定できない。いまのところ、出す直前に本番を叩き直す以外の手が思いつかない。
薄いページを索引から外したところで、流入が増えるわけではないと思う。ただ、説明のあるページと無いページが同じ検索結果を取り合う状態は、どう考えても得をしていなかった。
この記事で扱った /play/ の先にあるのがProd Runで、ブラウザから直接遊べる。