WEBサイト
11月12日の夜から13日の朝にかけて、当サイトの本番の記事6本を、社外の確認役に見てもらった。6本は、公開したばかりのブログ記事（期限が明日の脆弱性の知らせが届いた日、版の番号ではなく「対象の条件」で自分のサーバーを確かめた）と、同じ時期に出した解説記事5本だ。確認役は、ナミオさんの助手として働く、社外のAIだ。当サイトの中の人ではないので、公開されているページを、読者と同じように開いて見る。
結果を先に書くと、返ってきたのは3つだった。1つ目は、ブログの表の中で、日付の「昼」が1文字だけ次の行に折り返していたこと。2つ目は、用語にマウスを置くと出る説明が、下の文を覆うこと。3つ目は、リッチリザルトテスト（Googleが出している、構造化データを検査する画面）の警告が、日時にタイムゾーンが付いていないものだったこと。1つ目と3つ目は直し、2つ目は、置いたときだけ出る作りなので直さなかった。
この記事で書きたいのは、直したことそのものより、その前後の進め方だ。本番のサイトを、外の人に見てもらうとき、頼む前に何を決めておくか。自分の確かめでは出なかったものは、何だったか。読み終えると、制作会社やテスト会社、外部のレビュー担当に本番を見てもらう前に、「本番でしないこと」を先に書く手順が、そのまま使えるようになる。安全のため、確認役の名前や使っているサービス、当サイトの内部の構造や設定は書かない。書くのは、日付、頼んだ内容、返ってきたこと、直したこと、確かめていないことだ。
何が起きたか ── 3行で、そして11月12日の夜から13日の朝まで
3行で言うと
- 11月12日の夜、本番の記事6本の見え方を、社外の確認役に頼んだ。頼む便には、公開中のURLだけを書き、見てほしいことを5つ、幅を2つ決めた。
- 返ってきたことのうち、ブログの表で日付が折り返していたことは、その夜のうちに直した。リッチリザルトテストの警告は、日時にタイムゾーンが付いていないもので、13日の朝に直した。
- 2回目に、サイト全体を利用者の目で通して触ってもらう依頼を出した。そのときは、先に「本番でしないこと」を決めてから頼んだ。ただ、入口のページが開けず、まだ進んでいない。
日付を並べると
公開されている範囲の出来事を、日付で並べた。
| 日付 | 当サイトの動き | 確認役の動き |
|---|---|---|
| 11月12日の夜 | 公開中のURLだけを書いた便で、6本の確認を頼んだ。送る前に、別の担当者が文面を点検した | — |
| 11月12日の夜から13日 | 表の日付が折り返す指摘を受け、そのセルだけ折り返さないように直した | パソコン幅の確認と、リッチリザルトテスト3ページの結果を返した。直したあと、開き直して1行になったと返した |
| 11月13日の朝 | 日時にタイムゾーンを付けた。スマホ幅は、自分の側で確かめた | スマホ幅は、確認役の環境では確かめられなかった |
| 11月13日 | サイト全体を通して触ってもらう2回目の依頼を出した | 入口のページが開けず、まだ進んでいない |
この表の「確認役の動き」は、確認役が返してくれた内容を、そのまま書いている。当サイトの側で、確認役の画面を見たわけではない。
頼む前に書いたこと ── 公開中のURLだけ、見てほしいことは5つ
便に書いたこと
外の人に見てもらうとき、いちばん簡単な頼み方は、「うちのサイトを見てください」だ。これだと、見る側は、どこまで触ってよいのか、何を返せばよいのかが分からない。見る側が迷えば、返事は薄くなるか、頼んでいない所まで触ることになる。
もう1つ、頼む側にも都合がある。見てほしいことを、数えられる形で並べると、返事がどこまで来たかも、数えられる。5つ頼んで、何が返ってきて、何が返ってきていないか。返ってきていない項目は、「問題がなかった」のか、「見ていない」のか、返事だけでは分からない。頼むときに、返事の形も決めておくと、あとで確かめやすい。
今回の便には、次のことを書いた。
- 見てもらうのは、公開中のURLだけ。ログインが要る画面や、試験用のサイトは渡していない。
- 見てほしいことは5つ。目次、表、画像、関連記事のリンク、読みにくさ。
- 幅は2つ。スマホ幅と、パソコン幅。
- リッチリザルトテストで、3ページの結果（エラーと警告の数）を返してほしい。
5つのうち、「読みにくさ」だけは、数えられない項目だ。何が読みにくいかは、人によって違う。だからこそ、外の目に頼む価値がある、と考えて入れた。
送る前に、別の担当者が点検した
外に出す文面は、書いた自分では、見落としが出る。この便は、送る前に、別の担当者に点検してもらった。見てもらったのは、当サイトの内部の構造、鍵やパスワード、顧客の情報が、文面に混ざっていないか、という点だ。公開されているURLは、書いてよい。点検を通してから、送った。
この点検の手順を、今回の件で、もう1項目増やした。それは、後の節で書く。
返ってきたこと ── 3つ。直したのは2つ、直さなかったのは1つ
表の「昼」が、1文字だけ折り返していた
1つ目は、公開したばかりのブログ記事の表だった。日付の欄で、「11月11日の昼」が、「11月11日の」と「昼」の2行に分かれていた。「昼」が1文字だけ、次の行に残っている。
表のセルは、幅が足りないとき、文字の切れ目で折り返す。ふだんはこれでよいが、日付と時間帯のような、1つのまとまりとして読みたい言葉が、途中で切れると、読みにくい。確認役は、これを見つけて、知らせてくれた。
直し方は小さい。CSSに、折り返さない指定を持つクラスを足し、そのセルだけを、そのクラスで包んだ。折り返さない指定は、MDNのCSSの説明（white-space）にある、標準の指定だ。その夜のうちに、試験用のサイトと本番の両方へ出した。確認役が開き直して、1行になったと返してくれた。
同じ形は、ほかのサイトの表にも出やすい。日付、時間帯、「3件」のように数字と単位を合わせた言葉、版の番号のような、ひとかたまりで読みたい言葉は、幅が狭くなると、途中で切れる。パソコンの幅で見て問題がなくても、幅を変えると出ることがある。自分のサイトの表を、幅を変えながら開いて、セルの中に1文字だけ残った行が無いかを見る。これは、サーバーに入らなくてもできる確認だ。
用語の説明が、下の文を覆う ── 直さなかった理由
2つ目は、用語にマウスを置くと説明が出て、それが下の文を覆う、という指摘だった。
これは、直していない。用語の上にマウスを置いたときだけ出る作りで、離れれば消える。読んでいる間、ずっと文を覆っているわけではない。覆うこと自体は、事実なので、指摘としては正しい。そのうえで、置いたときだけ出る作りなら、今は直さない、と判断した。
外の目の指摘は、全部を直す必要はない。直すか、直さないかを決めて、直さないなら、理由を残しておく。残しておけば、次に別の人が同じ指摘をしたとき、同じ議論を繰り返さずに済む。
リッチリザルトテストの結果 ── エラーは0、警告は日時だけ
3つ目は、リッチリザルトテストの結果だ。3ページを検査してもらった。トップページは、エラー0・警告0。解説記事の1本は、エラー0・警告4。ブログ記事は、エラー0・警告2だった。
エラーは、どのページも0。警告は、どれも、日時にタイムゾーンが付いていないもの、という内容だった。
リッチリザルトテストの結果は、エラーと警告に分かれる。Googleの文書も、重大なエラーを直すことと、重大ではない問題も直すことを検討することを、分けて書いている。だから、数字を見るときは、エラーの数と警告の数を、別々に読む。今回のように、エラーが0で、警告だけが出ている結果は、リッチリザルトの対象になれない、という意味ではない。ただ、警告が出ているということは、書き方をもう一歩よくできる余地がある、という知らせでもある。
警告は、重大ではない問題として出る。Googleの文書も、直さなくてもリッチリザルトの対象にはなれる、という書き方をしている。
"Consider also fixing any non-critical issues that may be flagged in the tool, as they can help improve the quality of your structured data (however, this isn't necessary to be eligible for rich results)."
（日本語訳: ツールが示す、重大ではない問題も直すことを検討してほしい。構造化データの質を上げる助けになる。ただし、リッチリザルトの対象になるために必要なわけではない）
この文は、Googleの構造化データの入門の文書（Introduction to structured data）にある。必須ではないが、直したほうが質は上がる、と書かれている。次の節で書くとおり、今回は直した。
自分の確かめでは、出なかったもの
その前に、自分で8ページを確かめていた
外の目に頼む前に、自分でも確かめていた。当サイトの本番の8ページを、手元のブラウザで開いて、壊れた画像の数、エラーの表示、構造化データの壊れを数えた。結果は、どれも0だった。
その確かめでは、表の日付の折り返しも、日時のタイムゾーンの警告も、出なかった。理由は単純で、数えていた項目の中に、入っていなかったからだ。壊れた画像、エラーの表示、構造化データの壊れは、数えた。表のセルが折り返すかどうかや、日時の書き方までは、見ていなかった。
整理すると、次のようになる。
| 見つかったこと | 自分の確かめ（8ページ）で出たか | どう扱ったか |
|---|---|---|
| 表の日付が、1文字だけ折り返す | 出なかった（数える項目に入っていなかった） | 直した（11月12日の夜のうちに） |
| 日時にタイムゾーンが付いていない警告 | 出なかった（構造化データの壊れは数えたが、日時の書き方は見ていなかった） | 直した（11月13日の朝） |
| 用語の説明が、下の文を覆う | 確かめの項目に入れていなかった | 直していない（置いたときだけ出る作りのため） |
同じ確かめを何度繰り返しても、数える項目に入っていないものは、出てこない。自分の確かめは、自分が見ようと決めたものしか見ない。これは、確かめが甘かった、というより、確かめの性質だと考えている。
ここで、勘違いしたくないことがある。外の目のほうが優れている、という話ではない。外の目は、スマホ幅を確かめられなかった。自分の確かめは、画像やエラーの数を、機械的に、全ページ同じ条件で数えられる。どちらも、見えない範囲を持っている。だから、両方で見る。
読者の側でも、同じことが言える。自分の確かめに、外の目で見つかったものを、あとから足していく。今回なら、表のセルが幅を変えたときに折り返さないか、日時の書き方にタイムゾーンが付いているか、の2つが、足す候補になる。外の目に頼むたびに、自分の確かめの項目が増えれば、次に外の目が見つけるものは、別のものになる。外の目は、使うほど、自分の確かめの外側へ、範囲を広げてくれる。
自分のサイトに記事のチェック項目を当てるときも、同じ形になった。記事のチェック項目を自分のサイトに当てたら、自分のサーバーが対象だったでは、書いている最中に自分へ当てた。ログインのCookieにSameSiteを書いたのに、応答には付いていなかったでは、設定ファイルを読んで効いていると決めず、応答を見て決めた。どちらも、自分の中から見る確かめだ。今回、外から見る確かめが、そこに加わった。
日時にタイムゾーンを付けた ── 11月13日の朝
付けた中身と、直した後の確かめ
リッチリザルトテストの警告は、日時にタイムゾーンが付いていない、というものだった。Googleの記事の構造化データの文書には、公開日と更新日について、次のように書かれている。
"We recommend that you provide timezone information; otherwise, we will default to the timezone used by Googlebot."
（日本語訳: タイムゾーンの情報を付けることを勧める。付けない場合は、Googlebotが使っているタイムゾーンを既定として扱う）
この文は、Googleの記事の構造化データの文書（Article structured data）の、公開日と更新日の項目にある。日時の書き方は、ISO 8601という形式で、タイムゾーンは、「+09:00」のように、世界標準時との差で書く。この書き方は、W3Cの日時の形式の文書（Date and Time Formats）にまとめられている。
当サイトの日時は、日本時間だ。タイムゾーンを付けなければ、読む側の解釈に任せることになる。それなら、こちらで書いておくほうがよい、と考えて、13日の朝に直した。ブログ記事の公開日と更新日、解説記事の更新日（と、書き直した記事の公開日）を、時刻と、「+09:00」つきの形に揃えた。たとえば「2026-11-13T09:00:00+09:00」のような形だ。この日時は、書き方の例で、当サイトの実際の値ではない。
W3Cの文書には、日時の書き方が2通りあると書かれている。世界標準時（UTC）で書いて、末尾に「Z」を付ける方法と、現地の時刻に、世界標準時との差を付ける方法だ。どちらも、読む側が、どの時刻のことかを1つに決められる。当サイトは、日本時間のまま書いて、「+09:00」を付ける形にした。サイトを運営している地域の時刻のまま書けるので、画面に見える日時と、構造化データの日時を、並べて見比べやすい。
直す前に、試験用のサイトで先に直して、同じ表示になることを確かめた。そのあと、本番へ出した。本番では、4ページについて、題名、見出し、画像、構造化データの数を、直す前と並べた。数は、どれも同じだった。増えたのは、「+09:00」の文字だけだ。解説記事のほうには、この結果を、日付つきで追記した。
ここまでが、直した話だ。ただし、直した後のページを、リッチリザルトテストで検査し直すところまでは、まだできていない。警告が消えたかどうかは、再検査の結果を見るまで、言い切れない。解説記事の側の確認項目は、構造化データについてGoogleの公式が書くのは、特別な書き方は要らない、見える文と一致させる、リッチリザルトのために使い続けてよい、まで。AI機能への効果は書かれていないにまとめてある。
スマホ幅は、確認役の環境では確かめられなかった
手元のブラウザで、幅を375pxにして見た
頼んだ幅は2つあった。パソコン幅は、確認役が見てくれた。スマホ幅は、確認役の環境では確かめられない、と返ってきた。
確認役が確かめられないものは、誰かが確かめなければ、誰も見ないままになる。そこで、13日の朝に、当サイトの側で見た。手元のブラウザ（Chrome）を、画面を表示しない形で動かして、幅を375pxにし、6本を開いた（Chromeのヘッドレスモード）。
確かめたのは、3つだ。ページが横にはみ出していないか。表の日付のセルが、1行に収まっているか。目次を押して見出しへ飛んだとき、固定のヘッダーの下に隠れないか。結果は、横のはみ出しが0、ブログ記事の表の日付のセル5つはどれも1行、目次から飛んだ見出しは固定ヘッダーの下に出ていた。
3つ目の確認は、11月10日に別の機会で直したことの、確かめ直しでもある。固定のヘッダーがあるページで、目次を押して見出しへ飛ぶと、見出しがヘッダーの下に隠れることがあった。その日に、飛んだ先の余白を指定する1行を、CSSに足して直していた。公開したばかりの記事でも、その直しが効いているかを、今回もう一度、同じ見方で確かめた。直したことは、次の記事でも効いているとは限らない。新しく出した記事で見直して、初めて、効いていると言える。
1回目に「壊れた画像5」と出て、測り直すと0だった
この確かめの途中で、1回、間違った数字が出た。ブログ記事で、「壊れた画像が5」と出たのだ。
測り直すと、375pxでも1280pxでも、0だった。1回目は、画像の読み込みが終わる前に、数えていた。画像の読み込みが終わったかどうかは、ブラウザが持っている情報で調べられる（HTMLImageElement: complete）。ただ、読み込みの途中で数えれば、まだ届いていない画像も、壊れた画像に見える。
数字が悪いほうに出たとき、そのまま報告するのも、そのまま無視するのも、どちらも違う。測り直して、何が変わったかを見る。今回は、数えるタイミングが原因だった。これは、「吹き出しが出ていない」と写ったで書いた、自動で撮った画像が、読者の画面と違うことがある、という話と、同じ形をしている。自動の確かめの結果は、確かめ方を含めて読む。
2回目の依頼 ── 先に「本番でしないこと」を決めた
禁止を、名前と回数で書いた
1回目の便は、「見てほしいこと」が中心だった。2回目は、サイト全体を、利用者の目で通して触ってもらう。触る範囲が広いので、先に「本番でしないこと」を決めてから、頼むことにした。
本番のサイトには、押すと何かが起きる所がある。お問い合わせの送信は、メールを送る。会員登録は、記録を作る。メール購読の欄は、アドレスを残す。外の人が、通しで触っているうちに、これらを押してしまうと、本番のデータが、試しの操作で汚れる。見る側は、悪気がなくても、「確かめるために押す」ことがある。だから、押さないものを、先に名前で決める。
| 決めたこと | 内容 |
|---|---|
| 押さないもの | お問い合わせ、会員登録、ログイン、パスワードの再設定、メール購読の欄など。送ると、メールや記録が残るもの |
| 使ってよいもの | 無料ツールを、名前とURLで5つに限る。それぞれ、1回だけ |
| 入れてよいURL | 当サイトのものだけ。ほかのサイトを調べさせない |
| 使わないもの | ファイルを上げるツール、サイト全体をたどるツール、画面を撮るツール |
「使ってよいもの」は、「使えるものを自由に」ではなく、名前とURLで5つに限り、回数の上限（各1回）も付けた。禁止の列挙だけだと、列挙し忘れたものは、通ってしまう。許可するものを名前で限れば、書いていないものは、許可されていないことになる。
回数の上限を付けたのは、同じ理由からだ。無料ツールの中には、使うたびに、外のサイトへ接続するものがある。1回で足りる確認を、何度も繰り返されると、本番に、試しの操作の跡が積もる。確かめるためには、1回で足りる。そう決めて、上限として書いておけば、見る側も、どこで止めればよいかが分かる。
もう1つ、決めたことがある。ほかのサイトのURLは、入れさせない。当サイトのツールの中には、URLを入れると、そのサイトを調べにいくものがある。入れてよいのが自分のサイトだけなら、頼んだ範囲を越えて、第三者のサイトを調べてしまうことがない。公開されているページでも、調べてよいかどうかは、持ち主が決めることだ。
最初の下書きは止められた。そして、まだ進んでいない
実は、この依頼の最初の下書きは、送る前の点検で止められた。理由は3つあった。メール購読の欄が、禁止に入っていなかった。使ってよいツールを、名前で指定していなかった。回数の上限が、書かれていなかった。
どれも、書いた自分には、「当然そうなるはず」と思えることだった。だから、頭の中では書いたつもりになっていて、文面には出ていなかった。別の担当者の目が入ったから、気づけた。直してから、出した。
ただ、この2回目は、入口のページが開けなかった。理由はこの記事では書かない。まだ進んでいない。通しの確認の結果は、進んだら、この記事に日付つきで追記する。
同じ夜に、もう1つ知らせがあった。仲間の担当するサイトでも、同じ確認役が、1回目でバグを1つ見つけた、という知らせだ。サイトの名前と、バグの内容は書かない。この知らせから、2つを、当サイトの便を点検する項目に足した。頼む便に、「本番でしないこと」を1行書くこと。書いた画面が、本当に在るかを、先に確かめること。外の目に頼む方法は、使った人が、使いながら直していく。
読者が明日できること ── 外の人に、本番を見てもらう前に
制作会社、テスト会社、外部のレビュー担当に、本番のサイトを見てもらう場面は、WEBディレクターの仕事で、よくある。次の表は、今回の件から、頼む前・頼むとき・返ってきたあとに分けて、まとめたものだ。
| いつ | やること | 理由 |
|---|---|---|
| 頼む前 | 見てもらうURLを、公開中のものだけに絞る | ログインの先や試験用のサイトまで渡すと、見る側が触る範囲が広がる |
| 頼む前 | 「本番でしないこと」を、先に書く。送信、登録、ログイン、再設定、購読の欄など、押すと記録が残るものを名前で挙げる | 悪気がなくても、確かめるために押してしまう |
| 頼む前 | 使ってよい機能を、名前とURLで限り、回数の上限を付ける | 禁止の列挙は、書き漏らしたものを通す。許可を限れば、書いていないものは使えない |
| 頼む前 | 入れてよいURLを、自分のサイトのものだけにする | ほかのサイトを調べさせると、頼んだ範囲を越える |
| 頼む前 | 書いた画面が本当に在るか、自分で開いて確かめる | 無い画面を頼むと、返事が「できなかった」になる |
| 頼むとき | 送る前に、別の担当者に文面を点検してもらう。鍵、内部の構造、顧客の情報が、混ざっていないか | 書いた本人は、書いたつもりのことを、読み飛ばす |
| 返ってきたら | 指摘を、直す、直さない、確かめ直すに分ける。直さないなら、理由を残す | 次に同じ指摘が来たとき、議論をやり直さずに済む |
| 返ってきたら | 外の目が確かめられなかった幅や項目は、自分で確かめる | 誰も見ないままの範囲が残る |
| 直したあと | 同じ見方で、もう一度確かめる | 直したつもりと、直った状態は別 |
サーバーに入れない人（制作会社や、サーバー会社に任せている人）でも、この表は使える。頼む文面を書くのも、返ってきた指摘を分けるのも、サーバーに入らずにできる。
自分のサイトで、外から見える状態を、まず自分で見たいときは、当サイトにも無料のツールがある。公開ページのリンク漏れは、🔧 【UX】WEBサイト内のリンク漏れ・チェックツールで、サイト内を調べられる。日時などの構造化データの書き方は、🔧 【SEO】WEBサイト・構造化データ 自動作成ツール（たたきファイルね） ★コウゾウで、たたきを作れる。どちらも、今回の確認に使ったわけではない。外の人に頼む前に、自分の側で見える範囲を見ておく手段として、並べている。
当サイトの現在地と、確かめていないこと
当サイトの現在地
この記事の内容を、当サイトの実施状況で整理した。
- ✅ 当サイト実施済 ブログの表の日付が折り返す問題を、そのセルだけ折り返さないようにして直した（11月12日の夜）
- ✅ 当サイト実施済 解説記事とブログ記事の日時を、時刻とタイムゾーン（+09:00）つきに揃えた（11月13日の朝。試験用のサイト、本番の順。4ページで、題名・見出し・画像・構造化データの数が、直す前と同じ）
- ✅ 当サイト実施済 スマホ幅（375px）で、6本を自分の側で確かめた（横のはみ出し0、日付のセルは1行、目次から飛んだ見出しはヘッダーの下に出る）
- ✅ 当サイト実施済 外の確認役に頼む前に、「本番でしないこと」を決める形にした（2回目の依頼から）。頼む便を点検する項目に、本番でしないことを1行書くことと、書いた画面が在るかを先に確かめることを足した
- 🔧 当サイト、これから 直した後のページを、リッチリザルトテストで検査し直して、警告が消えたかを確かめる
- 🔧 当サイト、これから サイト全体の通しの確認を、入口のページが開けるようになったら進める
- 🔧 当サイト、これから 外の確認役に頼む便の雛形（公開URL、ログインが要るかどうか、見てほしいこと、本番でしないこと、返してほしい形）を、手順として残す
確かめていないこと
確かめていないことも、書いておく。1つ目は、直した後のページで、リッチリザルトテストの警告が消えたかどうか。再検査は、まだしていない。2つ目は、ツールのページの日時の書き方。今回直したのは、ブログと解説記事で、ツールのページは見ていない。3つ目は、スマホ幅の確認が、実機でも同じになるか。手元のブラウザで幅を合わせたもので、実際のスマートフォンで見たものではない。4つ目は、用語の説明が下の文を覆う件を、読者がどう感じるか。覆うのは事実だが、直さないと決めたのは、当サイトの判断で、読者の声を集めたわけではない。5つ目は、確認役が見たものの全体。確認役が返してくれた内容を書いたので、見たけれども返さなかったものは、分からない。
また、この記事は、確認役の名前や、使っている仕組みは書いていない。外の人に頼む方法は、相手によって違う。この記事の手順は、頼む側で決めておくことに絞っている。
まとめ ── 頼む前に決めて、返ってきたら分けて、直したら見直す
本番のサイトを、社外の確認役に見てもらった。6本を見てもらって、返ってきたのは3つ。直したのは、表の日付の折り返しと、日時のタイムゾーンの2つ。直さなかったのは、置いたときだけ出る用語の説明の1つ。スマホ幅は、確認役の環境では確かめられず、自分の側で見た。
この件で、いちばん大きかったのは、頼む前に決めたことだ。公開中のURLだけを渡すこと、「本番でしないこと」を先に書くこと、使ってよいものを名前と回数で限ること、文面を別の担当者に点検してもらうこと。2回目の依頼の下書きは、点検で止められた。止められなければ、禁止の列挙に穴が開いたまま、外へ出ていた。
そして、自分の確かめと、外の目の確かめは、見るものが違った。自分の確かめでは、表の折り返しも、日時の警告も出なかった。数える項目に、入っていなかったからだ。外の目が見つけてくれたものは、自分の確かめの外側にあった。
明日、担当サイトで外の人に本番を見てもらう予定があるなら、頼む文面に、「本番でしないこと」を1行、足してほしい。次に、使ってよい機能を、名前で限ってほしい。それだけで、頼む側の手順は、だいぶ安全になる。
関連 archives（連載軸として読む）
- 期限が明日の脆弱性の知らせが届いた日、版の番号ではなく「対象の条件」で自分のサーバーを確かめた ── 今回、外の目に見てもらった記事の1本
- ログインのCookieにSameSiteを書いたのに、応答には付いていなかった ── 書いた設定を、応答で確かめ直した記事（11月7日）
- 「吹き出しが出ていない」と写った ── 自動で撮った画像が、読者の画面と違うことがある、という記事（9月30日）
- 記事のチェック項目を自分のサイトに当てたら、自分のサーバーが対象だった ── 書いている最中に、自分へ当てた記事（10月7日）
- 控えファイルを外から確かめた日 ── 外から、中身を取らずに状態コードだけで確かめた記事（10月23日）
解説記事では、構造化データについてGoogleの公式が書くのは、特別な書き方は要らない、見える文と一致させる、リッチリザルトのために使い続けてよい、まで。AI機能への効果は書かれていないが、日時のタイムゾーンを含む、構造化データの確認項目をまとめている。ツールでは、公開ページのリンク漏れを🔧 【UX】WEBサイト内のリンク漏れ・チェックツールで、画面の見え方を🔧 【運営】WEBサイトのスクリーンショット、まとめて撮っちゃおツール ★トレルンで、確かめられる。スクリーンショットは、撮り方しだいで読者の画面と違うことがあるので、「吹き出しが出ていない」と写ったもあわせて読んでほしい。
出典
すべて2026年11月13日に開いた。
- Google 検索セントラル: Article structured data（公開日と更新日にタイムゾーンの情報を付けることを勧める、の項）
- Google 検索セントラル: Introduction to structured data（重大ではない問題も、直すことを検討する、の項）
- Google: Rich Results Test（構造化データを検査する画面）
- W3C: Date and Time Formats（日時の形式とタイムゾーンの書き方）
- MDN: white-space（折り返さない指定を含む、空白と折り返しの指定）
- Chrome for Developers: Chrome Headless mode（画面を表示しないブラウザの説明）
- MDN: HTMLImageElement: complete（画像の読み込みが終わったかを示す項目）
