/products?sort=priceや/search?q=shoesを見ても、すぐにDisallow: /*?とはしません。並び替え、フィルタ、ファセット、tracking、session、pagination、内部検索を分けます。
query stringを実URLでテストします
User-agent: *
Disallow: /*?sort=
testerでブロック対象と例外の両方を確認します。
重複だけならcanonicalも検討します
tracking URLならcanonical、redirect、リンク生成の整理で十分な場合があります。公開ページを検索結果から外したい場合はnoindexを検討します。
ファセットは価値のある状態を残します
検索需要のある絞り込みと、ほぼ無限に増える組み合わせを同一扱いにしません。全?を一括ブロックする前にクロール価値を分けます。
クロールとインデックスを分離します
robots.txtはアクセス、noindexは取得可能なページのインデックス制御です。meta robotsとの比較で判断レイヤーを確認できます。
本番でも同じテストを繰り返します
URLマトリクスを作り、公開後はcheckerで実際のファイルを確認します。
Faceted navigationは価値のある組み合わせを先に決めます
Googleは現在、faceted navigationがほぼ無限のURL空間を作り得ることを明示しています。検索価値のない組み合わせならcrawlを制限する選択肢があります。一方、crawlさせる必要があるfacetsは、パラメータ順を安定させ、重複・無意味な組み合わせを避け、結果がない状態には実際の 404 を返します。
tracking、内部検索、sort、filterを同じ扱いにはしません。utm_source はリンク設計やcanonical、内部検索はindex価値、sortはcrawl waste、色・サイズ・カテゴリfacetsはlanding page価値を個別に判断します。
URLを生成する側も直します
robots.txtはリンク自体を消しません。filter UI、pagination、JavaScript、sitemapを確認し、不要な組み合わせをアプリ側で生成しないようにできるなら、その方が長期的に保守しやすいです。
パラメータを用途別に棚卸しします
query parameterを一括でblockする前に、tracking、sort、pagination、internal search、facet、session、campaignなど用途を分類します。たとえば utm_source は通常、crawl制御よりもlink hygieneやcanonicalの問題です。一方、内部検索の ?q= や無限に組み合わせられるsort/filterはcrawl spaceを膨らませやすいため、生成方法そのものを見直す価値があります。商品カテゴリの色・サイズ・ブランドなど、検索需要のあるfacetはlanding pageとして残す判断もあり得ます。
facetをcrawl可能にする場合はparameter orderを安定させ、同じ状態を複数URLで表現しないようにします。結果が0件の組み合わせをすべて同じカテゴリへredirectすると、crawlerは無意味なURLを延々発見できます。空状態には適切な404を返す、内部linkから不要な組み合わせを生成しない、sitemapに価値のあるURLだけを載せる、といったapplication側の整理も必要です。
変更前後をURLマトリクスで比較します
代表URLを「indexさせたい」「crawlだけ許可」「crawl不要」「存在してはいけない」に分け、Googlebotなど対象User-agentでtesterを実行します。robots.txtだけでなくcanonical、noindex、status codeも記録します。blockを追加した後に重要facetまで閉じていないか、逆に不要URLが内部linkから増え続けていないかをproduction logやSearch Consoleで確認します。
運用時はログと内部リンクも見ます
ruleを追加した後は、server logやcrawl reportでparameter URLへのrequestが本当に減ったかを確認します。同時に、navigationやfilter UIが不要なURLを新しく生成し続けていないかも見ます。robots.txtだけで症状を隠すのではなく、URL生成量そのものが減っていることを成功条件にします。
