Maison_de_chatのブログ

【実体験レポート】ChatGPTで始める副業 – 最先端AI活用で在宅収益化に挑む新たな働き方を更新中！

内部改善ロードマップVol.1【前編】｜Day1–4で整える“AIに強いブログの土台”：robots.txt・サイトマップ・INP計測・サイト名＆Favicon最適化

お問い合わせはこちらから！

ブログの内部改善って、「どこから手を付ければいいの？」と迷いやすいですよね。でも、最初の4日間で“最低限そろえておきたい土台”が固まれば、そのあとの速度改善や構造化データ、内部リンク設計までスムーズに進みます。

今回の**内部改善ロードマップVol.1【前編】（Day1–4）**では、検索エンジンとAIクローラーのどちらにも“伝わりやすい”状態を作るための 4つの基礎 に取り組みます。
それが robots.txt／サイトマップ／INP計測／サイト名 & Favicon 正規化 の4セット。

どれも初心者の方がつまずきやすい領域ですが、実は「細かい設定」よりも 判断基準 が大事なんです。
このブログでは、はてなブログやWordPressなど、CMSユーザーでも迷わず進められるように、専門用語や操作画面に寄りすぎず、本質的な“見方”と“チェック項目”を中心に解説します。

4日後には、あなたのブログが
「クロールされやすい・発見されやすい・測定しやすい・ブランドとして一貫した」
そんな“AIにも読者にも強い土台”へと変わっているはずです。

 

 

 

本ブログでわかること

  • robots.txtでやってはいけないブロックの判断基準

  • サイトマップの構成ルールとlastmod運用の考え方

  • INP（Core Web Vitals）の簡易計測ルートと優先度の付け方

  • サイト名 & Favicon を正しく正規化するチェックポイント

  • 4日間で実施すべき内部改善の“到達ライン”

 

 

 

Day1｜robots.txtの“余計なブロック”検査

原則＝阻害しない（インデックス制御はmetaで）

robots.txtは“インデックスをコントロールする場所”ではなく、
「クロールしてもらう／しない」を明示するだけのファイルです。

ところが、初心者ほどここで“やりすぎ”が起きがち。
「見られたくないページ＝Disallow」という発想で、記事一覧・画像ディレクトリ・CSS・JSまでブロックしてしまうケースをよく見ます。

しかし、インデックスの要・不要は meta robots か Search Console の削除ツールで扱うのが原則。
robots.txtで制御しようとすると、Googleがページの品質を判断するためのリソース（CSS/JS）が読めなくなるため、結果的に SEO の評価も下がりやすくなります。

Day1での目標はシンプル。
「検索エンジンが必要な情報にアクセスできる状態か？」
を確認し、余計なブロックを排除することです。

robots.txtの過剰ブロックを見つけて除去し、CSS/JS/画像など必要リソースのクロール阻害を防ぐ確認手順を示す図。

 

絶対NGの例（CSS/JS/画像の一括ブロック など）

以下のようなDisallowが入っていたら、ほぼ確実に“改善ポイント”です。

  • Disallow: /wp-includes/（JS/CSSを含むためNG）

  • Disallow: /assets/（画像・CSS・JSを含むディレクトリ一括ブロック）

  • Disallow: /*.js$（JavaScript全ブロック）

  • Disallow: /*.css$（CSS全ブロック）

特に画像ディレクトリのブロックは、画像検索での流入がゼロになるうえ、構造化データ（Logo など）にも影響します。

NG例を見つけたら、まずは「なぜこれが入っているのか？」を確認し、不要なら削除します。
CMSテーマやセキュリティプラグインが自動生成している場合もあるため、手動編集前にバックアップも忘れずに。

 

AIクローラー方針の明示（許可/禁止の考え方）

2024–2025年以降で増えているのが、
AIクローラー（GPTBot・ClaudeBotなど）への対応方針です。

判断基準は次の2つだけ。

  1. ブログ内容をAI検索に出したいか？

  2. キャプチャコスト（負荷）が気になるか？

AI検索からの流入を見込みたいなら、許可するほうが得です。
一方、「データ利用ポリシーに抵抗がある」「負荷が気になる」という場合は、User-agent 単位でブロックも可能です。

ただし、AIクローラーは日々増えるため
「禁止したいものだけ個別に（Allowは書かない）」
というスタンスが安全です。

 

チェックリスト（配置・User-agent・Allow/Disallowの整合）

Day1の最終チェックは以下の4点。

  • 正しい場所に配置されているか？
    → https://example.com/robots.txt の直下のみ有効

  • User-agent の書き方が統一されているか？
    → 大文字小文字の揺れや*の扱い

  • Allow/Disallow が矛盾していないか？
    → 上から順に評価されるが、最後にAllowが勝つCMSもある

  • CSS/JS/画像を誤ってブロックしていないか？

このチェックがクリアすれば、ブログは**「クロールに不必要な障害をつくらない」状態**になります。

 

 

 

Day2｜サイトマップ運用ルールを決める

基本構成（単一 or インデックス＋分割／月別）

サイトマップは、記事数や更新頻度で運用方法が変わります。

  • 記事50本以下 → 単一 sitemap.xml

  • 記事50〜300本 → sitemap_index.xml + 分割（記事／固定ページ）

  • 300本以上 → 月別 or カテゴリ別に分割

重要なのは
「Googleに“更新の意図”が伝わりやすい構造か？」
という点。

サイトマップの分割設計・lastmod運用・GSCで見る3指標と、URL数やエラーを残す運用ログの流れを整理した図。

分割するほど管理は手間ですが、その分 更新頻度の高い部分だけ更新されるため、クローラーが効率よく巡回できます。

 

lastmodの更新ガイド（“意味のある更新”だけ）

初心者が陥りがちなミスが、
「ちょっとした文言修正でも lastmod を更新してしまう」
というパターン。

Googleは lastmod の過剰更新を嫌いませんが、
頻繁に更新されすぎると“更新の価値”が薄れ、クローラーの効率も落ちます。

lastmod を更新すべきなのは、

  • 見出しを変更した

  • 画像を差し替えた

  • 構造化データを修正した

  • 重要な段落を書き換えた

といった 「ユーザー体験が変わる更新」 のみで十分です。

 

送信後に見る数字（取得ステータス／検出URL／エラーの読み）

GSC のサイトマップ画面で見るべき数字は3つだけ。

  1. 取得ステータス：成功か？

  2. 検出されたURL数：サイトマップ記載数と一致しているか？

  3. エラーや警告：パス・ドメイン・重複の問題はないか？

特に「取得できませんでした」は、
URLが間違っている／リダイレクトしている／noindexを含むなどの可能性が高いので、最初にチェックします。

 

実務ログテンプレ（URL・件数・エラー備考）

Day2の仕上げとして、次のようなログを残します。

  • 対象：sitemap.xml / sitemap_index.xml

  • URL数：XX → 送信後の検出数：XX

  • エラー：なし／○○（備考）

  • 更新日：YYYY/MM/DD

  • 次回更新予定：記事追加後／月末

“運用ログ”を残すことで、
後から問題が起きたときに原因追跡が楽になるのがメリットです。

 

 

 

Day3｜INPの“簡易計測”を始める

計測の全体像（PSI→DevTools→記録）

Day3では、Core Web Vitals の中でも特に改善効果が大きい
INP（Interaction to Next Paint） の計測に着手します。

最初に使うのはこの3つ。

  1. PageSpeed Insights（PSI）

  2. Chrome DevTools（パフォーマンス）

  3. 記録シート（Before/After）

まず PSI で フィールドデータ（実際のユーザー体験） を確認し、
次に DevTools で 紫バー（イベント処理） を見て原因を推測します。

INPをPSIとDevToolsで把握し、外部JS・画像・ウィジェットを起点に施策を当ててBefore/Afterを記録する流れの図。

 

紫バー（イベント処理）の読み方

DevTools の「パフォーマンス」記録で出てくる紫のバーは、
クリックやタップに反応するための処理時間を示しています。

  • 紫バーが長い → 重いJSが走っている

  • 紫バーが点在 → ウィジェットや外部スクリプト

  • 赤い三角（警告） → レイアウト反映に時間

ここで「どのJSがボトルネックか？」をざっくり把握し、
Day5（後編）につなげるのが目的です。

 

初動の3方向（外部JS棚卸し／画像最適化／ウィジェット整理）

初心者でも“今日からできる”INP改善として、まずは以下の3つ。

  1. 外部JSの棚卸し
    → 解析・SNS埋め込み・フォントなど重複がないか

  2. 画像最適化
    → 大きすぎる画像がINPを押し下げていないか

  3. ウィジェット整理
    → サイドバーやフッターに“動くパーツ”が多いと負荷増

これらを見直すだけで、
INP改善の8割は“方向性が掴める*ようになります。

 

記録の型（Before/Afterと施策メモ）

INP改善は“やりっぱなし”が一番もったいないです。
施策の影響を確認するために、次のように記録します。

  • Before：INP（PSI）＝ XX ms

  • 表示速度の傾向：良好／要改善

  • 対応：外部JS整理／画像圧縮

  • After：XX ms（翌日or翌週のPSIで確認）

  • メモ：効果あり／変化なし

数値が安定するまで数日かかるため、
1回値に一喜一憂しないのが大事です。

 

 

 

Day4｜サイト名（Site name）& Favicon を正規化

主名と別名の決め方（短く通じる名称を主名に）

Googleが検索結果で表示する“Site name”は、
**主名（primary）と別名（alternate）**で構成されています。

ポイントは
「ユーザーが一番認識しやすい短い名称を主名にする」
こと。

例：

  • 主名：ブログライターLab

  • 別名：ブログライターラボ｜内部改善ガイド

この2つが整理されていれば、後の評価も安定しやすくなります。

Site nameの主名/別名整理と、Faviconの1ホスト統一・サイズ条件・キャッシュ対処までをチェックできる正規化手順の図。



Faviconの条件（1ホスト1個・正方形・48px＋）

Favicon は「ただ置けばOK」ではありません。

必須条件は次の3つ。

  1. 正方形であること

  2. 48px以上のサイズを持つこと（最近は512推奨）

  3. 1ホスト1個に統一されていること

特に3つ目が重要で、
/favicon.ico と /images/favicon.png が混在すると、
ブラウザやGoogleがどちらを採用するかブレます。

 

反映ズレの対処（差し替え→URL変更→キャッシュ整理）

Faviconは反映にタイムラグが出やすい要素です。

改善するための順番は、

  1. ファイルを差し替える

  2. ファイル名を変更する（例：favicon-v2.png）

  3. HTMLのlinkタグも更新する

  4. ブラウザ・サーバーキャッシュを削除

  5. Googleが再取得するのを待つ（数日〜1週間）

ここまでやれば、ほぼ確実に最新のアイコンへ更新されます。

 

 

用語ミニ辞典（初心者向け）

robots.txt

検索エンジンに「このURLはクロールしてOK／NG」を伝えるためのファイル。インデックス制御ではなく“アクセスの可否”を示すだけなので、CSS・JS・画像を誤ってブロックしないことが最重要。

サイトマップ（sitemap.xml）

ブログ内の重要URLを検索エンジンへ効率よく伝えるためのリスト。更新頻度によって単一・分割・月別などの運用がある。lastmodの正しい更新ルールが品質に影響。

lastmod

サイトマップ内で「このページをいつ意味のある更新をしたか」を示す日付。細かな文言修正では更新しないのが原則で、ユーザー体験が変わる修正のみ更新が望ましい。

INP（Interaction to Next Paint）

Core Web Vitals のひとつで「クリック・タップの反応の速さ」を数値化した指標。外部スクリプトや重いJSが原因で悪化しやすい。PSIとDevToolsの両方で計測する。

Favicon

検索結果・ブラウザタブ・スマホのショートカットなどに表示される小さなアイコン。1ホスト1個・正方形・48px以上が前提条件。差し替え時はキャッシュが反映を遅らせがち。

 

 

 

まとめ：Day1–4で“クロール×発見×体感”の土台を完成させる

Day1〜4の目的は 「検索エンジンと読者のどちらにも伝わりやすい、強い内部構造を作る」 ことです。

  • Day1：robots.txt による“余計なブロック”を取り除き、クロール障害をゼロへ。

  • Day2：サイトマップ運用で、クローラーが迷わない“情報の地図”をつくる。

  • Day3：INP計測を開始し、体感速度の改善ポイントを把握する。

  • Day4：サイト名＆Faviconを正規化し、ブランドとしての一貫性を整える。

この4日間を終えると、ブログは**「発見されやすい・巡回されやすい・測定しやすい」AIにも強い初期状態**に到達します。
ここが整っていると、次の「速度改善」「外部スクリプト削減」「内部リンク設計」などの施策が、すべてスムーズに進むようになります。

 

 

次回：Vol.1【後編】｜Day5–7：外部スクリプトの軽量化／検証ダッシュボード／仕上げチェック

前編で“基礎体力”が整ったので、次回は
ブログの反応の遅さの正体に直接アプローチする3日間 に入ります。

  • Day5：外部スクリプトの棚卸し＆軽量化ルール

  • Day6：GSC & PSI の検証ダッシュボードの読み方

  • Day7：到達点の固定化と、次の30日へ向けた準備

AI検索・モバイル表示・ユーザー体験のどれにも効く“数字で改善が分かる3日間”です。
後編で、いよいよ体感の軽さをつくる施策をまとめて仕上げます。

 

 

 

今回はここで終わりにしたいと思います！

最後までお読みいただきありがとうございました！


このブログでは「ChatGPT×副業」をテーマに、AIをフル活用したリアルな副業チャレンジを発信しています🎶

むずかしい話はナシで、「ちょっとやってみたいかも」と思えるような内容を目指しています😁

私は現在、ChatGPTを使ってTシャツのデザインを作って販売したり、

LINEスタンプのキャラ制作に挑戦したりしています👍

デザインの知識ゼロでも、AIの画像生成機能を使えばかなりいい感じになりますよ！

ブログの内容やSEO対策も、ぜんぶChatGPTに相談しながら書いています。

アイデアが出ないときも、相棒みたいに助けてくれます🎶

さらに、楽天ルームのレビュー文章もChatGPTと一緒に考えたり、

X（旧Twitter）の投稿や運用方法も提案してもらったりと、あらゆる場面でAIに頼っています。😅

「AIって便利そうだけど、自分にも使えるのかな？」

と思っている人には、ぜひ読んでほしいです。

このブログは、AI初心者でも副業が始められるように、

体験ベースでわかりやすく書いています。

私の成功も失敗もまるごとシェアしていくので、よかったら気軽に読んでいってくださいね。

Xでも日々の活動をゆるっと更新しているので、ぜひのぞいてみてください！

明日のあなたがより豊かになりますように😌

それでは、おやすみなさい😴