www化の308を入れてもSearch Consoleの旧プロパティは集計を続ける──URLプレフィックス型で5週間データを取り逃した記録

apexドメインからwwwへ308恒久リダイレクトを入れても、Search Consoleのプロパティは自動では移らない。URLプレフィックス型プロパティは、指定した文字列で始まるURLしか集計しないからである。当サイトは2026年7月10日にこのリダイレクトを入れ、Search Consoleには非wwwのURLプレフィックス型プロパティしか無い状態で35日間「検索流入がほとんど無い」と読み違えた。直し方は、www側のURLプレフィックス型プロパティを追加する（またはDNSでドメインプロパティを立てる）ことと、新プロパティが空でも旧プロパティを叩いてから「データが失われた」と言うことの2点である。旧プロパティは308の後も集計を続けている場合がある。

1. URLプレフィックス型プロパティは「www.」の有無・プロトコルの違いを別物として扱う。Google公式はhttp://www.example.com/dresses/1234がhttp://example.com/プロパティに入らない例を明示している（2026年8月14日確認）
2. 旧（非www）プロパティは308導入後も集計を続けていた。 2026年8月14日15:04（日本時間）にSearch Console APIで2026-05-01〜08-14を取得したところ、非wwwプロパティは60日分・19クリック・526表示を返した。「新プロパティが空＝過去データが消えた」は誤りだった
3. 同じプロパティ・同じ期間・同じ時刻でも、aggregationTypeがbyPropertyなら526表示、byPageなら556表示、クエリ次元で合計すると80表示になる。合計が合わないのは不具合ではなく仕様である

症状1：403 PERMISSION_DENIED は「そのURLが存在しない」ではない

Search Console APIのURL Inspection（urlInspection.index.inspect）に、プロパティ範囲外のURLを渡すと次が返る。2026年8月14日、当サイトのサービスアカウントで実際に取得したレスポンス本文をそのまま貼る。

{
  "error": {
    "code": 403,
    "message": "You do not own this site, or the inspected URL is not part of this property.",
    "status": "PERMISSION_DENIED"
  }
}

同じ日に3通りの組み合わせを試したが、原因が違っても返るメッセージは1種類だった。

メッセージは「You do not own this site（このサイトを所有していない）, or the inspected URL is not part of this property（または検査対象URLがこのプロパティに含まれていない）」と2つの原因をorで並べている。所有権があっても、URLがプロパティ範囲外なら同じ403になる。403を見て「所有権の設定に失敗した」と判断すると、原因はホスト名の食い違いや末尾スラッシュの脱落なので、いくら所有権を直しても直らない。

APIリファレンスは3番目のケースを明記している。siteUrlの説明は「Required. The URL of the property as defined in Search Console. Note that URL-prefix properties must include a trailing / mark.（必須。Search Consoleで定義したプロパティのURL。URLプレフィックス型プロパティは末尾のスラッシュを含める必要がある）」、inspectionUrlの説明は「Required. Fully-qualified URL to inspect. Must be under the property specified in "siteUrl".（必須。検査する完全修飾URL。"siteUrl"で指定したプロパティの配下でなければならない）」である（最終更新2024年7月23日UTC・2026年8月14日確認）。

症状2：新しく作ったプロパティが「データなし」で始まる

もう1つの症状は、www側のプロパティを追加した直後の画面である。当サイトが2026年8月14日8時57分（日本時間）に保存した日次スナップショット（data/gsc/2026-08-14.json）は、www側について次の状態だった。

{
  "site": "https://www.ai-jitan-hub.com/",
  "totals_28d": null,
  "queries": [],
  "pages": []
}

totals_28dがnull、クエリもページも空配列である。ここで「7月10日以降のデータは永久に失われた」と結論したのが、この記事を書くきっかけになった誤りだった。

原因：URLプレフィックス型は「文字列の先頭一致」でしかない

Search Consoleヘルプ「Add a website or platform property to Search Console」（2026年8月14日確認）は、URLプレフィックス型プロパティをこう定義している。

Includes only URLs with the specified prefix, including the protocol (http/https).

（指定したプレフィックスを持つURLのみを含む。プロトコル（http/https）も含めて判定する）

同ページは、http://example.com/というプロパティに対して何が入り何が入らないかを記号付きで並べている。

✔ http://example.com/dresses/1234

🅧 https://example.com/dresses/1234 - https does not match

🅧 http://www.example.com/dresses/1234 - www. does not match

（http://example.com/dresses/1234は一致する。https://...はhttpsが一致しない。http://www.example.com/...はwww.が一致しない）

さらに「Similarly, if you support multiple subdomains (such as example.com, m.example.com, and www.example.com) you must add a separate property for each subdomain.（同様に、複数のサブドメインをサポートしているなら、サブドメインごとに別のプロパティを追加しなければならない）」と書かれている。ドメインプロパティ側の説明は「Domain properties automatically include both www and non-www prefixes; that is, if you specify www.example.com as your property URL, the property will be created as example.com, and include data from both www.example.com and example.com.（ドメインプロパティはwww付きとwww無しの両方のプレフィックスを自動的に含む。つまりwww.example.comをプロパティURLとして指定してもexample.comとして作成され、両方のデータが含まれる）」で、wwwの有無をまとめたいならDNS認証のドメインプロパティを使う設計になっている。

つまりwww化は「サイト側の1行の設定変更」だが、Search Console側では「別のプロパティを作る作業」になる。 片方だけ済ませても、画面は何のエラーも出さない。ただ数字が減るだけである。

308を入れても、プロパティは移らないし移転は一気に終わらない

当サイトのリダイレクトはNext.js（16.2.7）のnext.config.tsにある。

async redirects() {
  return [
    {
      source: "/:path*",
      has: [{ type: "host", value: "ai-jitan-hub.com" }],
      destination: "https://www.ai-jitan-hub.com/:path*",
      permanent: true,
    },
  ];
}

Next.js公式のredirectsリファレンス（最終更新2026年6月30日）はpermanentについて「true or false - if true will use the 308 status code which instructs clients/search engines to cache the redirect forever, if false will use the 307 status code which is temporary and is not cached.（trueなら308ステータスコードを使い、クライアントや検索エンジンにリダイレクトを恒久的にキャッシュするよう指示する。falseなら一時的でキャッシュされない307を使う）」と書いている。2026年8月14日にcurlで確認した実際のレスポンスヘッダは次のとおりで、記事URLでも同じ308が返った。

HTTP/2 308
location: https://www.ai-jitan-hub.com/
server: Vercel

Google Search Centralの「Redirects and Google Search」（最終更新2026年4月14日UTC）は、308を恒久リダイレクトの一種として挙げたうえでこう説明する。

Googlebot follows the redirect, and the indexing pipeline uses the redirect as a signal that the redirect target should be canonical.

（Googlebotはリダイレクトをたどり、インデックスのパイプラインはそのリダイレクトを「リダイレクト先が正規であるべき」というシグナルとして使う）

ここで重要なのは「シグナル」であって「即時の切り替え」ではない点である。「How to move a site」（最終更新2026年6月17日UTC）は移転完了の条件を次のように書く。

To consider a site move complete, Googlebot will have to visit every URL on your old and new site at least once. There are no fixed crawl frequencies; how fast Googlebot crawl depends on the size of your site, and the speed of crawling that's possible. The move takes place on a per-URL basis.

（サイト移転が完了したとみなすには、Googlebotが旧サイトと新サイトの全URLを少なくとも1回は訪問する必要がある。クロール頻度は固定されていない。移転はURL単位で進む）

同ページはSearch Consoleについても「Make use of Search Console. Search Console is your friend, especially during a site move. Verify data for each property separately in Search Console.（Search Consoleを使うこと。特にサイト移転中は頼りになる。プロパティごとに個別にデータを確認すること）」、移転手順の要約では「Monitor the traffic on both the old and new URLs.（旧URLと新URLの両方でトラフィックを監視すること）」と書いている。旧プロパティを消さずに両方見るのは、公式が明示している手順である。

実測：旧プロパティは308の後も集計を続けていた

2026年8月14日15時04分（日本時間）に、Search Console APIのsearchanalytics.queryで同じ期間（2026-05-01〜2026-08-14）を両プロパティに投げた結果が次である。dataStateは既定（final）。

旧プロパティ https://ai-jitan-hub.com/（308でwwwへ恒久リダイレクト済み）

日付次元の60行は2026年6月14日から8月12日までで、308を入れた7月10日以降の日付も含まれている。この数字を見るまで、当サイトはwww化以降の実績を「永久に取り返せない」と書いていた。誤りだった。

新プロパティ https://www.ai-jitan-hub.com/（同じ瞬間に取得）

※dataState: "all"だけは未確定データを含むため、同じ日のうちに動く。この記事の検品時（同日15時25分）に同じリクエストを投げ直すと101表示になっていた（data/gsc/recheck-2026-08-14-1519.json）。既定（final）の数字は同じ21分間で1つも動いていない。

新プロパティのデータは2026年8月12日から始まっており、過去には遡らない。遡らないのは新プロパティであって、旧プロパティのデータが消えたわけではない。

罠：同じプロパティ・同じ期間でも、次元を変えると合計が変わる

上の表で、旧プロパティの表示回数が526・556・80と3通り出ている。これは公式ドキュメントで説明できる。

1. ページ単位とプロパティ単位で数え方が違う（526 vs 556）

Search Consoleヘルプ「Performance report (Search results): Dimensions and data groupings」（2026年8月14日確認）は明記している。

Aggregation: Choosing the Pages dimension aggregates table data by page rather than by property. The graph data is always aggregated by property, regardless of the dimension selected.

（集計：ページ次元を選ぶと、表のデータはプロパティ単位ではなくページ単位で集計される。グラフのデータは、選んだ次元にかかわらず常にプロパティ単位で集計される）

APIのaggregationTypeの説明も同じ構造で、「If aggregated by property, all data for the same property is aggregated; if aggregated by page, all data is aggregated by canonical URI.（プロパティ単位なら同一プロパティのデータがまとめられ、ページ単位なら正規URI単位でまとめられる）」となっている。

数え方の違いは「What are impressions, position, and clicks?」のヘルプにある例が分かりやすい。1つのナレッジパネルに同じサイトの5ページ分のリンクが載っていた場合、プロパティ単位のグループ化では「www.example.com - 1 impression」の1回だけ、ページ単位のグループ化では5ページがそれぞれ1回ずつ、合計5回になる。1回の検索結果表示が、数え方によって1にも5にもなる。 当サイトの30回の差（556−526、プロパティ単位合計の5.7%）は、この種の重複の積み上がりとして説明が付く範囲にある。ただし当サイトが確認したのは合計値の差までで、どの表示がどう重複したかは特定していない。

2. クエリ次元は匿名化とデータ切り捨てで大きく欠ける（80）

同じヘルプページのクエリの節はこう書く。

Anonymized queries: Some queries are omitted from the report to protect user privacy. These are called anonymized queries. They’re included in chart totals, unless a query filter is applied (for example, "queries containing" or "queries not containing" a given string).

Data truncation: Due to internal limitations, Search Console stores and shows only the most important data rows. Not all queries beyond anonymized queries are shown in the table. The most complete list of queries can be exported using bulk data exports.

（匿名化クエリ：ユーザーのプライバシー保護のため一部のクエリはレポートから除外される。これらは匿名化クエリと呼ばれ、クエリフィルタ（「〜を含むクエリ」「〜を含まないクエリ」など）を適用しない限りグラフの合計には含まれる／データの切り捨て：内部的な制限により、Search Consoleは最も重要なデータ行だけを保存・表示する。匿名化クエリ以外にも表に出ないクエリがある。最も完全なクエリ一覧は一括データエクスポートで書き出せる）

当サイトのクエリ次元で拾えたのは45クエリ・表示80回で、これはプロパティ単位合計526の**15.2%**にすぎない。クリックに至っては19のうち2しか紐づかない。個人サイト規模では、クエリ次元の合計はサイト全体の合計にまったく届かないと考えたほうがよい。 「クエリ一覧を全部足しても合計に合わない」は正常動作である。

3. 表の行数上限とタイムラグ

「Troubleshooting data discrepancies」（2026年8月14日確認）は、グラフと表の合計がずれる理由を4つ挙げている。要点は「Table row limits: The table can display a maximum of 1,000 rows（表は最大1,000行まで）」「Anonymized queries（匿名化クエリ）」「Aggregation difference（集計の差異）」「Discrepancy in totaling（合計の不一致）」である。なおAPIのrowLimitは「Valid range is 1–25,000; Default is 1,000」なので、APIから叩けば画面の1,000行制限は超えられる。当サイトの取得はrowLimit: 25000で、返った最大行数は79行だった（上限には当たっていない）。

同ページは反映の遅れについて「Time lag: There can be a lag between when the numbers are calculated and when they are visible. Collected data is usually available in 2–3 days.（数値が計算されてから見えるまでには遅れがある。収集されたデータは通常2〜3日で利用可能になる）」とも書く。8月14日に取得して確定データの末尾が8月12日だったのは、この2〜3日の範囲に収まっている。

対処：何をどの順でやるか

1. 正規ホストと一致するプロパティを作る。 wwwとapexをまとめたいならDNS認証のドメインプロパティ、パスやプロトコルで切り分けたいならURLプレフィックス型を正規ホストで追加する
2. 旧プロパティを削除しない。 公式は移転時に「旧URLと新URLの両方でトラフィックを監視する」と書いている。旧プロパティは308の後も集計を続けうる
3. 新プロパティが空でも「失われた」と言う前に旧プロパティを叩く。 過去データは新プロパティに遡らないだけで、旧プロパティ側には残っている場合がある
4. サイトマップの送信先を確認する。 wwwのURLが並んだサイトマップを非wwwプロパティに送っていると、プロパティ範囲外になる。旧ホストのURLを含むサイトマップが必要なら、旧ホスト用に別途用意して旧プロパティへ送る
5. APIで検証するときはsiteUrlの末尾スラッシュとホスト名を先に疑う。 403のメッセージは所有権とプロパティ範囲外を区別しない
6. 合計を比べるときは集計単位を揃える。 ページ次元の合計とサイト全体の合計は、仕様上一致しない

踏んだ記録（2026年7月10日〜8月14日・当サイト1件）

当サイトはNext.js 16.2.7＋Vercelで運用しているニュース／解説サイトで、後述の全数検査を走らせた2026年8月14日11時51分時点の記事数は351本である。時系列は次のとおり。

気づくのに35日（ちょうど5週間）かかった。 画面にはエラーも警告も出ない。出るのは「表示回数が減った」というグラフだけで、それは「露出が減った」とも「計測範囲から外れた」とも読める。当サイトは前者だと読み、記事の質やSEO施策のせいだと考えて1か月を使った。

同じ日に全351記事をURL Inspection APIで全数検査した結果も、7月10日を境に様子が変わっていた。

公開日で切ると差がはっきりする。308を入れた2026年7月10日を境に、それ以降・8月7日までに公開した64本は98.4%（63本）がインデックス済みなのに対し、7月9日以前の251本は12.4%（31本）しかインデックスされていない。8月8日以降の36本は16.7%（6本）だが、これは公開から日が浅く未認識のものを含む。本文の長さでは説明が付かず（登録済み100本の本文中央値が3,190.5字なのに対し未登録201本は3,530字で、未登録の方が長い）、説明が付いたのは公開日だった。

さらに、www側で「検出・未登録」かつ7月9日以前公開の186本から40本を無作為抽出し、旧ホスト側で同じ検査をかけたところ、13本（32.5%）が旧ホストではSubmitted and indexedだった。同じ記事が、ホストを変えて検査すると別の答えを返す。

一方で、Googleが選んだ正規URLが非www側になっていた記事は351本中2本だけだった（glm-5-2-zhipu-1m-context-open-sourceとmidjourney-guide-pricing-howto-2026。どちらもサイト側が宣言している正規URLはwww）。旧プロパティが集計を続けている理由を、この2本だけで説明することはできない。 手元のデータで言えるのは「集計は続いていた」という観測までである。

正直な但し書き

「旧プロパティが集計を続ける仕組み」は特定できていない。 公式ドキュメントは「表示回数・クリック・掲載順位は正規URLに帰属する」「移転はURL単位で進み、Googlebotが全URLを1回は訪問する必要がある」と書いており、当サイトの351本のうち201本が「検出・未登録」＝クロールされていない状態にある。これらと整合する説明は立てられるが、Googleの内部処理を確認したわけではない。本記事で確定した事実は「308を入れて35日経った旧プロパティが、その期間を含むデータを返した」という観測1件である。

同じ日のうちに数字が動いた。 2026年8月14日11時34分に保存したファイル（history-nonwww-2026-08-14.json）では日付次元59日・18クリック・523表示、ページ次元79ページ・18クリック・553表示だったが、同日15時04分には日付次元60日・19クリック・526表示、ページ次元79ページ・19クリック・556表示になっていた。差分は8月12日分の確定である。一方、同じリクエストを同日15時25分に投げ直したときは、旧プロパティの確定（final）側の数字は上の表の6通りすべてが15時04分と同一で、動いたのは未確定データを含むdataState: "all"だけだった（98→101表示・recheck-2026-08-14-1519.json）。時刻を揃えずに取った数字を比べると、確定前の差を「不具合」と読み違える。

403の3ケースはすべて同じメッセージだった、というのは当サイトのプロパティ構成での結果である。 サービスアカウントには両プロパティのオーナー権限がある状態で試している。権限が無い場合に別のメッセージが返るかどうかは検証していない。

日本語版ヘルプは機械翻訳の注記付きページがある。 本記事で引用したSearch Consoleヘルプの日本語ページには「このページには、AI 技術を使用して翻訳されたコンテンツが含まれている場合があります」の注記がある。そのため引用は英語版の原文を採り、訳は当サイトで付けた。訳の責任は当サイトにある。

効果はまだ測っていない。 2026年8月14日に、旧ホストURLを載せたサイトマップの旧プロパティへの登録と、関連記事の表示数を3件から8件に増やす変更を行ったが、その結果はこの記事の時点では出ていない。インデックス状態は日単位で揺れるため、1回の比較で結論を出さない方針を取っている。

ドメインプロパティに切り替えた場合の挙動は未検証である。 sc-domain:ai-jitan-hub.comのプロパティ自体は追加してあるが、2026年8月14日時点で権限はsiteUnverifiedUser（DNS認証が未完了）で、APIからは読めていない。ドメインプロパティで旧ホストのデータがどう見えるかは試していない。

出典

• Add a website or platform property to Search Console - Search Console Help（2026年8月14日確認）: https://support.google.com/webmasters/answer/34592
• What are impressions, position, and clicks? - Search Console Help（2026年8月14日確認）: https://support.google.com/webmasters/answer/7042828
• Performance report (Search results): Dimensions and data groupings - Search Console Help（2026年8月14日確認）: https://support.google.com/webmasters/answer/17011259
• Performance report (Search results): Troubleshooting data discrepancies - Search Console Help（2026年8月14日確認）: https://support.google.com/webmasters/answer/17010575
• Method: index.inspect | Search Console API（最終更新2024年7月23日UTC、2026年8月14日確認）: https://developers.google.com/webmaster-tools/v1/urlInspection.index/inspect
• Search Analytics: query | Search Console API（最終更新2026年8月11日UTC、2026年8月14日確認）: https://developers.google.com/webmaster-tools/v1/searchanalytics/query
• Redirects and Google Search | Google Search Central（最終更新2026年4月14日UTC、2026年8月14日確認）: https://developers.google.com/search/docs/crawling-indexing/301-redirects
• How to move a site | Google Search Central（最終更新2026年6月17日UTC、2026年8月14日確認）: https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes
• redirects | next.config.js Options | Next.js（最終更新2026年6月30日、2026年8月14日確認）: https://nextjs.org/docs/app/api-reference/config/next-config-js/redirects
• AI時短ラボ 実測ログ: data/gsc/history-nonwww-2026-08-14.json／data/gsc/full-inspect-2026-08-14.json／data/gsc/2026-08-14.json／data/gsc/oldhost-check-2026-08-14.txt／data/gsc/recheck-2026-08-14-1519.json（いずれも2026年8月14日取得）