WEBサイトHTTPSは「ごく軽い」順位の信号として始まり、いまの文書は正規URLに選ぶ条件を書く ── http→httpsの転送で確かめる13項目（2026年10月時点）
HTTPSは「ごく軽い」順位の信号として始まり、いまの文書は正規URLに選ぶ条件を書く ── http→httpsの転送で確かめる13項目（2026年10月時点）
目次
- 01 何が書かれているか — HTTPSについて、Googleは3つの文書で別々のことを書いている。2014年は「ごく軽い」順位の信号、いまの文書は正規URLに選ぶ条件
- 02 なぜ・背景 — 「HTTPSは効くのか」は、3つの問いに分けると答えが読みやすい
- 03 この記事に出てくる用語
- 04 型別 — 適用範囲・公式が書いていないこと・確かめる順番
- 05 明日、自社のサイトで確認できることチェックリスト
- 06 代替・他の選択肢 — 転送の方法ごとの、公式の言い方と使い分け
- 07 当サイトの例 — 2026年10月19日に外から開いて確かめた。転送は1回で、サイトマップはすべてhttpsだった
- 08 このテーマは、ここまで
- 09 この記事のまとめ
01 何が書かれているか — HTTPSについて、Googleは3つの文書で別々のことを書いている。2014年は「ごく軽い」順位の信号、いまの文書は正規URLに選ぶ条件
引用について
この記事の「" "」で囲んだ英語の文は、公式の資料からの引用で、日本語訳は記事の筆者が付けたものである。原文は各出典のページで確認できる。各ページは2026年10月19日に開いて確かめた。ページの表記が「Last updated」の形のものは、その日付をそのまま書いている。
「HTTPSにするとSEOに効くのか」という問いの答えの出どころは3つある。2014年のブログ、いまのページエクスペリエンスの文書、正規URLの選び方の文書である。書かれている内容も、更新された時期も違うので、1つずつ読む。
2014年8月7日のブログが書いたこと
Google検索セントラルのブログ「HTTPS as a ranking signal」は、2014年8月7日の投稿である。数か月間のテストをしたあとで、こう書いている。
"We've seen positive results, so we're starting to use HTTPS as a ranking signal. For now it's only a very lightweight signal—affecting fewer than 1% of global queries, and carrying less weight than other signals such as high-quality content—while we give webmasters time to switch to HTTPS."
（訳: 良い結果が出たので、HTTPSを順位づけの信号として使い始める。いまのところは、ごく軽い信号にとどまる。世界の検索の1%未満に影響し、質の高いコンテンツのような他の信号より軽い扱いである。ウェブマスターがHTTPSに切り替える時間を設けているためだ。）
読み取れるのは3点である。HTTPSは順位づけの信号として使い始められたこと、その重さはごく軽いこと、影響を受けるのは世界の検索の1%未満であることだ。次の文は、将来について、こう書いている。
"But over time, we may decide to strengthen it, because we'd like to encourage all website owners to switch from HTTP to HTTPS to keep everyone safe on the web."
（訳: ただ、時間がたてば、強めることを決めるかもしれない。すべてのサイト運営者にHTTPからHTTPSへの切り替えを促して、ウェブの全員を安全に保ちたいからだ。）
「強めるかもしれない」は予告であって、強めたという報告ではない。
2014年のブログが、あわせて勧めたこと
同じブログは、切り替えの基本のヒントも並べている。検索に関わる2つは、次のとおりである。
"Don't block your HTTPS site from crawling using robots.txt"
（訳: HTTPSのサイトを、robots.txtでクロールから遮断しない。）
"Allow indexing of your pages by search engines where possible. Avoid the noindex robots meta tag."
（訳: 可能なら、ページを検索エンジンにインデックスさせる。noindexのrobotsメタタグは避ける。）
HTTPSの側を公開に出すときは、robots.txtの遮断とnoindexが残っていないかを見る。これは2014年から変わらない確認事項である。
いまのページエクスペリエンスの文書が書くこと
Google検索セントラルの「Understanding page experience in Google Search results」は、ページの下の表記が「Last updated 2026-09-22 UTC」である。文書は、ページの体験を見る質問を並べていて、その2つ目が、こうである。
"Are your pages served in a secure fashion?"
（訳: あなたのページは、安全な形で配信されているか。）
HTTPSは「質問の1つ」として、モバイル表示などと並んでいる。リソースの欄には「Search Console's HTTPS report」が挙がり、HTTPSのページを配信できているか、直すものは何かを見る報告と説明されている。FAQには、次の文がある。
"There is no single signal. Our core ranking systems look at a variety of signals that align with overall page experience."
（訳: 単独の信号はない。コアのランキングシステムは、ページ体験の全体に沿うさまざまな信号を見る。）
"Beyond Core Web Vitals, other page experience aspects don't directly help your website rank higher in search results."
（訳: Core Web Vitals以外のページ体験の側面は、サイトの検索順位を直接は押し上げない。）
文書は続けて、直接は押し上げなくても、サイトを使いやすくする点でランキングシステムが報いようとするものと沿っている、と書く。筆者が文書の本文を検索したところ、HTTPSだけを取り出して「順位の信号だ」と書いた文は見つからなかった。
正規URLを選ぶ文書が書くこと
「How to specify a canonical URL with rel="canonical" and other methods」は、表記が「Last updated 2026-07-10 UTC」で、HTTPSの節がある。
"Google prefers HTTPS pages over equivalent HTTP pages as canonical, except when there are issues or conflicting signals such as the following:"
（訳: Googleは、同じ内容のHTTPのページより、HTTPSのページを正規として選ぶ。ただし、次のような問題や、食い違う信号がある場合を除く。）
文書が挙げる「除く場合」は4つである。
- HTTPSのページの証明書（SSL証明書）が無効である
- HTTPSのページに、画像以外の安全でない依存（HTTPで読み込むもの）がある
- HTTPSのページが、ユーザーをHTTPのページへ、またはHTTPのページを通して転送する
- HTTPSのページのrel="canonical"が、HTTPのページを指している
さらに文書は、HTTPSが選ばれる動きを確実にする方法として、HTTPのページからHTTPSのページへ転送を入れること、HTTPのページからHTTPSのページへrel="canonical"を付けること、HSTSを実装することの3つを挙げている。
02 なぜ・背景 — 「HTTPSは効くのか」は、3つの問いに分けると答えが読みやすい
問い1: 順位の信号として効くのか
順位の信号としての話は、2014年のブログが出どころで、「ごく軽い」「1%未満」と書かれていた。いまの文書は、HTTPSを質問の1つに置き、Core Web Vitals以外の側面は順位を直接押し上げないと書く。どちらも、HTTPSにすれば順位が上がる、とは書いていない。
2014年のブログは「その年に何をしたか」の記録で、ページエクスペリエンスの文書は「いまのランキングをどう見るか」の説明である。2014年の信号がいまの仕組みでどう扱われるかは、公式の資料が現在形で書いていない。ここは書かれていないことを、書かれていないままにしておく。
問い2: 正規URLとして選ばれるのか
こちらは、検索結果に出すURLの選び方の話で、いまの文書がはっきり書いている。順位の話と違い、自分のサイトの側で確かめられる項目が多い。証明書、HTTPで読み込む部品、転送の向き、rel="canonical"の4つは、どれも自分で開いて見られる。
問い3: URLが変わる移転として、どう扱われるのか
Googleの「How to move a site」（Last updated 2026-08-20 UTC）は、移転の例の1つに「URL changes from HTTP to HTTPS」を挙げている。ドメインの変更と並ぶ、URLが変わる移転の一種という扱いである。文書は、次のように書く。
"301 and other permanent redirects don't cause a loss in PageRank."
（訳: 301やその他の永続的な転送は、PageRankの損失を生まない。）
移転の型はサイト移転は4パターンある ── URL変更を伴う移転で確認する15項目（2026年9月時点）で、301と被リンクの評価は301リダイレクトは被リンクの評価を引き継ぐか？ チェーンと着地点の落とし穴（2026年8月時点）で扱っている。この記事では繰り返さない。
利用者の側の安全は、別の話として残る
利用者の安全に関わる画面の話は、この記事の軸ではない。Chromeが、HTTPのページを開く前に確認の画面を出す話はChrome 154は、HTTPのページを開く前に既定で確認を出す。最終ページがHTTPSでも、転送の途中がHTTPなら出る ── 自社の入口を1つずつ開いて確認する13項目（2026年10月時点）に、混在コンテンツは参照元ページの更新とHTTPSの被リンク — リンク切れと混在コンテンツを自分で点検する（2026年8月時点）にまとめた。
03 この記事に出てくる用語
HTTPSとTLS
用語
HTTPSは、HTTPの通信を、TLS（Transport Layer Security）という暗号化の仕組みの上で行うものである。アドレスが「https://」で始まる。通信を暗号化することと、相手のサイトが本物かを証明書で確かめることの2つの役割がある。
転送（リダイレクト）と、永続・一時の違い
用語
転送は、あるURLを開いた人とGoogleを、別のURLへ送ることである。Googleの「Redirects and Google Search」は、永続的な転送は「新しい行き先を検索結果に出す」、一時的な転送は「元のページを検索結果に出す」と整理している。サーバー側の永続的な転送は301と308で、一時的な転送は302・303・307である。HTTPからHTTPSへの転送は、元に戻さないので、永続的な転送を選ぶ。
正規URL（canonical）
同じ内容が複数のURLで開けるとき、Googleが「代表」として選ぶ1つのURLを正規URLと呼ぶ。HTTPとHTTPSは、同じ内容が別のURLで開ける典型である。Googleの「What is canonicalization」は、正規URLを決める要素に「whether the page is served over HTTP or HTTPS」を含めて挙げている。
HSTS
用語
HSTS（HTTP Strict Transport Security）は、サイトが「このサイトには、HTTPSだけで接続してほしい」と、ブラウザに伝える仕組みである。サイトがStrict-Transport-Securityという応答ヘッダーを返し、ブラウザは、max-ageで指定された秒数のあいだ、そのサイトへのhttp://のアクセスを、送る前にhttps://へ書き換える。仕様はRFC 6797（2012年11月）である。
混在コンテンツ
HTTPSのページが、画像・スクリプト・CSSなどをHTTPで読み込む状態を、混在コンテンツと呼ぶ。詳しい点検は参照元ページの更新とHTTPSの被リンク — リンク切れと混在コンテンツを自分で点検する（2026年8月時点）で書いた。
04 型別 — 適用範囲・公式が書いていないこと・確かめる順番
🅰 適用範囲 — いまのサイトがどの状態かで、読む場所が違う
この記事は、独自ドメインを持ち、サーバーか管理画面の設定を触れるサイトを想定している。状態は3つに分かれる。
- HTTPのまま公開している: 証明書を用意し、転送を入れる。移転の文書の手順が最も関わる。
- HTTPSでも開けるが、HTTPも200で返す: 同じ内容が2つのURLで開く状態である。転送とrel="canonical"で、1つに寄せる。
- すでにHTTPSに寄せている: 転送が1回で済んでいるか、中身にHTTPが残っていないかを見る。
BloggerやShopifyのようなサービスを使っている場合について、転送の文書は「the platform may already have built-in redirect solutions」（訳: そのサービスに、転送の仕組みが最初から入っているかもしれない）と書いている。設定画面を先に見るほうが早い。
🅱 公式が書いていないこと
読んだ文書に書かれていなかったことを、先に並べる。
- HTTPSにしたとき、順位が何位上がるか、何%上がるか。数字は、どの文書にも書かれていない。
- いまの時点で、HTTPSの信号がどれだけの重さか。
- HSTSを入れたとき、順位が変わるか。正規URLの文書は、HSTSをHTTPSが選ばれる動きを確実にする方法の1つとして挙げているが、順位との関係は書いていない。
- 証明書の種類（無料か有料か）で、検索の扱いが変わるか。読んだ文書は、無効かどうか、ホスト名に合っているかどうかだけを問題にしている。
この4つは、「書かれていない」ことしか言えない。
🅲 手順 — 確かめる5段
手順1 — httpとhttpsを、同じ場所で開いて、ステータスを書き留める
トップ、記事、画像、robots.txt、sitemap.xml、存在しないアドレスの6種類を、http://とhttps://の両方で開く。「curl -sI」で、ステータスコードと行き先（Location）が出る。書き留めるのは、ステータスコードと行き先のアドレスである。
手順2 — 転送の回数と、行き先を数える
httpで開いたものが、何回の転送でhttpsの最終のアドレスに着くかを数える。Googleの移転の文書は「Avoid chaining redirects.」（訳: 転送をつなげるのを避ける）と書き、Googlebotは最大10回の転送をたどるが、ideally no more than 3 and fewer than 5（訳: 理想は3回以下、5回未満）という目安を示している。HTTPからHTTPSへの転送は、1回で最終のアドレスに着く形が最も短い。wwwの有無を合わせる転送が別に入っていると、2回になりやすい。
手順3 — canonical・サイトマップ・内部リンクを、httpsにそろえる
転送ができても、ページの中がhttpのままなら、食い違う信号が残る。正規URLの文書は、サイトマップについて、こう書く。
"Don't include the HTTP version of your pages in your sitemap or hreflang annotations rather than the HTTPS version."
（訳: HTTPS版ではなく、HTTP版のページを、サイトマップやhreflangに入れない。）
見るのは、ページのソースにあるrel="canonical"のアドレス、sitemap.xmlのloc、ページの中のリンクと画像のアドレスの3か所である。
手順4 — 証明書と、混在コンテンツを見る
証明書の期限と、サイトのホスト名が証明書に含まれているかを、ブラウザの鍵のマークから開いて見る。正規URLの文書は「Avoid implementing your SSL/TLS certificate for the wrong host-variant.」（訳: 違うホスト名の形のために、SSL/TLS証明書を実装するのを避ける）と書いている。wwwありとなしの両方で開いて、警告が出ないことを見る。証明書の更新の自動化はLet's Encryptの証明書は2027年2月10日から標準で64日になる ── 更新の設定の「日数の決め打ち」とARI対応を確かめる13項目（2026年10月時点）にまとめた。
手順5 — HSTSは、最後に入れる
web.devの「Enable HTTPS on your servers」（ページの表記は「Last updated 2015-03-27 UTC」で、古い資料である）は、こう書いている。
"Ultimately you should redirect HTTP requests to HTTPS and use HTTP Strict Transport Security (HSTS). However, that needs to happen later in the migration process."
（訳: 最終的には、HTTPのリクエストをHTTPSへ転送し、HSTSを使うべきである。ただし、それは移行の後の段階で行う必要がある。）
HSTSは、ブラウザが記憶する仕組みである。RFC 6797は、includeSubDomainsを付けると、そのドメインのサブドメインにも適用されると書き、実務上の影響を、第11.4節で別に論じている。HTTPのままで使っているサブドメインがあるなら、先に一覧にしてからにする。
実務のヒント
転送を入れるときは、転送の動きだけを変えて、ほかを変えないのが確認しやすい。移転の文書も「Change only one thing at a time」（訳: 一度に変えるのは1つだけにする）と書く。デザインの変更やCMSの入れ替えを同じ日にしないほうが、表示数が変わったときに原因を分けられる。
05 明日、自社のサイトで確認できることチェックリスト
以下は、HTTPSの扱いが、検索に出すURLの選び方と食い違っていないかを確かめるための項目である。1〜5番目は転送、6〜9番目はページの中、10〜11番目は証明書とSearch Console、12〜13番目はHSTSと確認の予定である。チェックの状態はブラウザに保存され、サーバーには送られない。
- 自社のトップを「http://」で始まる形で開き、アドレス欄が「https://」に変わるか、変わったあとの画面が表示されるかを書き留める
- curlの「-sI」でhttp://のトップを1回取得し、ステータスコードが301か308か（302ではないか）と、Locationの行き先を書き留める
- トップ・記事・画像・robots.txt・sitemap.xml・存在しないアドレスの6種類をhttp://で開き、行き先のパスが同じかを確認する
- 同じ6種類で、httpsの最終のアドレスに着くまでの転送の回数を数え、2回以上のものを書き出す
- wwwありとなし、httpとhttpsの4通りでトップを開き、最終的に1つのアドレスに着くかを確認する
- httpsの主要ページ5本のソースを開き、「http://」で始まる画像・スクリプト・CSSの数を数える
- 同じ5本のrel="canonical"のアドレスが「https://」で始まり、そのページ自身を指しているかを確認する
- sitemap.xmlを開き、locのうち「http://」で始まるものの数を数える
- robots.txtのSitemapの行が「https://」で始まるかを確認し、robots.txtがhttpsで200を返すかを確認する
- ブラウザの鍵のマークから証明書を開き、有効期限の日付を書き留め、30日以内なら更新の予定日を決める
- Search Consoleで、httpとhttpsの両方の形、またはドメインのプロパティが登録されているかを確認し、HTTPSの報告に出ている項目の数を書き留める
- HSTSを入れる前に、httpのままで使っているサブドメインがないかを一覧にして書き出す
- 転送を入れた日を記録し、30日後と90日後にSearch Consoleのインデックス登録のページ数を見る日を、カレンダーに入れる
06 代替・他の選択肢 — 転送の方法ごとの、公式の言い方と使い分け
HTTPからHTTPSへ送る方法は、1つではない
HTTPからHTTPSへ送る方法には、サーバー側の転送、meta refresh、JavaScript、HSTSがある。Googleの「Redirects and Google Search」が書く方法を表に並べる。HSTSはブラウザ側の仕組みなので、RFC 6797の言い方で書く。
| 方法 | 公式の言い方 | この記事での使い分け |
|---|---|---|
| サーバー側の301・308 | 永続的な転送。転送先を正規とする信号として使われる。正しく解釈される可能性が最も高いとして先頭に並ぶ | 基本の選択。Googleの移転の文書も、これを勧める |
| 302・303・307 | 一時的な転送。正規の信号としては使われず、元のページが検索結果に残りうる | HTTPSへの切り替えには使わない。元に戻さないので |
| meta refresh（0秒） | 永続的な転送として解釈される方法の1つ | サーバー側の転送が使えないときの次の候補。判定の基準はサーバー側の301が使えないとき、次に選ぶべきはどれか ── meta refreshとJavaScriptリダイレクトの判定基準を確認する13項目（2026年9月時点）にまとめた |
| JavaScriptの転送 | サーバー側の転送もmeta refreshも使えない場合に限る、と書かれている | 最後の手段。ブラウザでの動作に依存する |
| HSTS | RFC 6797では、HSTSのヘッダーは安全な通信で受け取ったときだけ有効で、安全でない通信で受け取ったときは無視される | 転送の代わりにはならない。最初の1回は、301などの転送が必要 |
表の読み方は、「どれが速いか」ではなく、どれが「元に戻さない移転だ」と伝える方法かである。RFC 6797は、HSTSのサイトがHTTPのリクエストを受けたときについて、こう書く。
"If an HSTS Host receives an HTTP request message over a non-secure transport, it SHOULD send an HTTP response message containing a status code indicating a permanent redirect, such as status code 301"
（訳: HSTSのホストが、安全でない通信でHTTPのリクエストを受けたら、301のような永続的な転送を示すステータスコードを含む応答を返すべきである。）
HSTSを使う場合でも、HTTPで届いたリクエストには301の転送を返すのが、仕様の書き方である。転送とHSTSは、どちらか一方を選ぶものではない。
当サイトの無料ツールとの使い分け
当サイトには、サイトの状態を確かめる無料のツールがある。🔧 WEBサイト総合分析・レポートツール — URLを入れて、HTTPS対応やセキュリティヘッダー（HSTSなど）を含む診断をするは、会員登録が不要で、診断項目にHTTPS対応とHSTSなどのセキュリティヘッダーを含んでいる。手順5でHSTSを入れたあとに、ヘッダーが出ているかを確かめる補助になる。
🔧 サイト内のリンク漏れ・アクセスステータスを調べるツール — Excelに出力できるは、サイトのHTMLにあるリンクや画像のアドレスを調べて、アクセスステータスをまとめる。転送の回数を数えるツールではないが、リンク先が200で開くか、404になるかを一覧にできるので、HTTPSへの切り替えのあとに壊れたリンクがないかを見るのに使える。
ホスティングやサービスの「HTTPSにする」設定を使うとき
注意
ホスティングやCMSの設定に「常にHTTPSを使う」のような項目があっても、設定した結果を、外から開いて確かめる。画面が「オン」でも、一部のパスだけ転送されない、転送が2回になる、という状態は画面では分からない。確認は手順1と手順2で行う。
07 当サイトの例 — 2026年10月19日に外から開いて確かめた。転送は1回で、サイトマップはすべてhttpsだった
2026年10月3日まで、httpのトップは200のままだった
当サイトでは、2026年10月3日まで、http://のトップが、httpsに転送されず200で開いていた。同じ内容が2つのURLで開く状態だった。同じ日に、httpsでなければ同じアドレスのhttpsへ301で送るように直し、httpsの10ページの応答が、直す前と同じであることを確かめた。この経緯は、運営者の作業の記録に残している。この記事では、外から見える応答だけを扱う。
今日の確認 — 8つのアドレスを、httpとhttpsで開いた
2026年10月19日の朝、手順1と手順2を、当サイトに当てた。8つのアドレスを、http://とhttps://の両方で開き、ステータスコードと、転送の回数を書き留めた。
| 開いたパス | httpで開いた応答 | 転送の回数 | 最終の応答 |
|---|---|---|---|
| /（トップ） | 301 | 1回 | 200 |
| /seo_article | 301 | 1回 | 200 |
| /ai_ron/archives/157 | 301 | 1回 | 200 |
| /robots.txt | 301 | 1回 | 200 |
| /sitemap.xml | 301 | 1回 | 200 |
| /seo_article/337 | 301 | 1回 | 200 |
| /tool/google_checker | 301 | 1回 | 200 |
| 存在しないパス | 301 | 1回 | 404 |
8つとも、httpで開くと301が返り、同じパスのhttpsに、1回の転送で着いた。httpsで直接開いたときの応答は、最終の応答と同じ（7つが200、存在しないパスが404）だった。存在しないパスが、転送のあとも404のまま届いたことが、手順1に「存在しないアドレス」を入れた理由である。404を返すべきアドレスがトップに送られると、移転の文書が避けるよう書く、無関係な1つの行き先への転送になる。
ページの中と、サイトマップを数えた
手順3に当たる確認も行った。トップ、解説記事の一覧、ブログ1本、解説記事1本、無料ツール1本の5ページのソースから、コメントの中を除いて数えると、「http://」で始まる画像・スクリプト・CSS・iframeなどの読み込みは0件、「http://」で始まるリンクも0件だった。5ページとも、rel="canonical"は「https://」で始まる、そのページ自身のアドレスだった。
2026年10月19日の9時21分に本番のsitemap.xmlを数えると、locが393件で、393件すべてが「https://」で始まっていた。「http://」で始まるものは0件である。robots.txtのSitemapの行は1行で、httpsのアドレスだった。
実務のヒント
見るのは、外から見える応答とソースだけで、サーバーの中を開く必要はない。手順1〜3は、管理画面に入れない担当者でも、自社のサイトで同じように行える。
確かめていないこと
この確認は、1台のパソコンから、2026年10月19日の朝に1回行った。次の点は確かめていない。
- 証明書の有効期限と発行元（手順4）。この記事の確認には含めなかった。
- Search Consoleの「HTTPS」の報告の表示。画面は開いていない。
- 転送を入れた前後で、検索の表示回数やクリック数が変わったか。2026年10月3日の前後の数字は、この記事では比べていない。
- 公開している全ページ。5ページのソースと、8つのアドレスを開いただけである。
公開済みのブログで、HTTPのアクセスの記録だけを数えて、回数を少なく書いてしまった例もある。HTTPとHTTPSでは、記録が別になっている場合がある。その経緯はAIは331回来たと書いた。実際は11,024回だった ── HTTPのログだけを52日間 見ていたに書いた。
08 このテーマは、ここまで
2012年11月 — HSTSの仕様（RFC 6797）
RFC 6797が、Strict-Transport-Securityヘッダーの仕様を定めた。HTTPで受け取ったヘッダーは無視する、という規則も、この時点で決まっている。
2014年8月7日 — HTTPSを順位の信号として使い始めたと、Googleが書いた
Google検索セントラルのブログが、HTTPSを「ごく軽い」順位の信号として使い始めたと書いた。
2026年7月10日 — 正規URLの文書の更新日
正規URLの文書の表記が「Last updated 2026-07-10 UTC」である。HTTPSを正規に選ぶこと、除く4つの場合が書かれている。
2026年8月20日 — サイトの移転の文書の更新日
移転の文書の表記が「Last updated 2026-08-20 UTC」である。転送を残す期間は「generally at least 1 year」（訳: 一般に少なくとも1年）と書かれている。
2026年9月22日 — ページエクスペリエンスの文書の更新日
表記が「Last updated 2026-09-22 UTC」である。HTTPSは質問の1つとして並んでいる。
この記事の確認日
2026年10月19日に、上の文書を開いて確かめた。当サイトの応答とソースは、同じ日の朝に測った。文書が更新されたら、日付を見て、この欄を書き足す。
現在の貴方のIPアドレス
このサイトで書いている人
