SEO

🚀 はじめに この記事でわかること Google Search Console（サーチコンソール／GSC）が何のための無料ツールかと、使うと何が良くなるか 登録後にまず触る場所（検索パフォーマンス・URL検査・サイトマップ・ページのインデックス登録・Core Web Vitals）の具体的なイメージ GSCがないと起きがちな困りごとと、次に学ぶとよい関連テーマ こんな人向け 中学生〜大人まで、IT知識がほとんどない人 「GSCってよく聞くけど、結局なに？」をやさしく知りたい人 初心者でも安心な理由 専門用語は身近なたとえで説明 このページだけで完結（最後に公式リンクも整理） ✅ 概要解説 Google Search Consoleとは何か あなたのサイトの“健康診断表＋連絡帳”。検索に出るまでの流れ（見つける→記録する→結果に並べる）を、Googleがどう見ているかを公式データで教えてくれる、完全無料の管理ツールです。 検索パフォーマンス：どんなキーワードで何回表示され、何回クリックされたかを可視化。 URL検査：特定ページがインデックス（検索用のデータベース登録） されているか、今すぐチェック＆登録リクエスト。 サイトマップ：サイト内URLの一覧表を渡して、発見・クロール・インデックスを助ける。 ページのインデックス登録（旧カバレッジ）：登録済み／未登録の理由と件数を確認し、修正→再検証まで行える。 Core Web Vitals：実ユーザーの体験に基づき、表示の速さ・反応・ズレを評価（LCP/INP/CLS）。 何のためにあるのか 現状把握：検索で何が起きているかを、推測ではなく公式数値で把握。 問題の早期発見：インデックス未登録、モバイルの使いにくさ、セキュリティ警告などを通知してくれる。 改善の近道：サイトマップ送信やURL検査で伝達・再クロールを促し、修正の効果検証まで一気通貫。 GSCがないとどうなるの？ 「表示されていない理由」がわからない：記事を書いても検索に出ない時、インデックス未登録なのか、技術的なエラーなのか、原因が見えにくい。GSCなら「未登録の理由」やエラーを特定できる。 タイムロスが増える：Googleが勝手に見つけてくれるまで待つだけに。サイトマップ送信やURL検査で能動的に伝えられるのがメリット。 体験の悪化に気づきにくい：Core Web Vitalsの実測データがないと、読み込みや反応の遅さに気づくのが遅れる。 どんな場面で使えるの？ 個人ブログ／小規模サイト：まずは検索パフォーマンスで「表示回数・クリック・平均順位」を把握、タイトル改善のヒントに。 新規公開／更新直後：URL検査でインデックス登録をリクエストして、認識を前倒し。 記事が検索に出ない：ページのインデックス登録（旧カバレッジ） で未登録理由を確認し、修正→検証。 大量のページを一括で知らせたい：サイトマップを作って送信。50,000URL/50MBなどの上限も公式に明記。 表示が遅い／ガクつく：Core Web VitalsでLCP・INP・CLSを確認し、改善の優先順位を決める。 💡 小話・豆知識 GSCに“毎日ログイン”は不要 重大な問題が発生するとメール通知が来ます。データが安定しているかは月1回程度の確認でもOK（もちろん更新の多いサイトはこまめに）。 URL検査は“ページ単位の救急窓口” 公開したばかりのURLを検査→インデックス登録をリクエストできます（上限あり）。レンダリングの様子もスクショで確認可能。 サイトマップの“正しい作法” 1ファイル50,000URL/50MBまで。大きい場合は分割しサイトマップインデックスで束ねるのが王道。UTF‑8で、絶対URLを使うのもポイント。 “旧カバレッジ”は名前が変わった 画面上では「ページのインデックス登録」として表示されます。未登録の理由（例：noindex、robots.txt、ソフト404 など）を確認→修正の検証で改善状況を追えます。 Core Web Vitalsは“体験の定期検診” レポートは実ユーザーのデータ（CrUX）に基づき、LCP/INP/CLSを「低速／改善が必要／良好」で判定。優先的に直すURLグループを探せます。 📚 参考リンク 公式サイト・ドキュメント Google Search Console 公式（概要・ログイン） search.google.com/search-console/about Google 検索セントラル｜Search Console の使い方（総合ガイド） developers.google.com/search/docs/monitor-debug/search-console-start URL 検査ツール ヘルプ（使い方・注意点） support.google.com/webmasters/answer/9012289 サイトマップの作成と送信（上限・形式・ベストプラクティス） developers.google.com/search/docs/crawling-indexing/sitemaps/build-sitemap Core Web Vitals レポート（LCP/INP/CLS の見方） support.google.com/webmasters/answer/9205520 百科・背景（読み物） Google 検索セントラル（SEO 入門・最新情報） developers.google.com/search 信頼できる外部情報（日本語） ページのインデックス登録（旧カバレッジ） の見方・対処（実践的） サクラサクのSEO｜解説記事（未登録理由・修正の検証） 記事1 / 記事2 URL検査の要点（インデックスリクエストやNG例） Nobilistaブログ（上限や注意点の整理） 記事 🛠️ 関連テーマ・次に理解すると良いこと インデックスの仕組み：クロール→インデックス→ランキングの流れ。未登録時の代表的な理由と対処（noindex／robots.txt／ソフト404 など）。 サイトマップ運用の実務：分割・インデックスファイル・lastmodの扱い・絶対URLの徹底。 Core Web Vitals 改善の第一歩：LCP（2.5秒以内）・INP（200ms未満）・CLS（0.1以下）を目標に、画像最適化／JS削減／レイアウトの安定化から。 GA4との組み合わせ：GSCで検索前、GA4で訪問後の行動を把握して、改善のPDCAをつなぐ（導線やコンバージョンの発見に有効）。 🎯 まとめ GSCは“検索に出るまで”を見える化する無料ツール（公式データで現状・問題・改善を把握）。 まずは検索パフォーマンス／URL検査／サイトマップ／ページのインデックス登録／Core Web Vitalsを覚えると効果的。 サイトが伸びない理由の多くは“見えないところ”にある。未登録・技術エラー・体験の遅さを公式レポートで特定→対処しよう。 次の一歩は、インデックスの仕組み理解 → サイトマップ運用 → 体験（CWV）改善の順で着実に。

🚀 はじめに：この記事でできること Hugo ＋ PaperMod ＋ GitHub Pagesで運用するブログに、Google Search Console（以下、Search Console） を導入するための完全ガイドです。 操作 → 目的 → 結果 → 注意/補足 の順で、初心者が迷いやすいポイント（URL構成・ユーザー/プロジェクトサイトの違い）も含めて整理します。 この手順を完了すると、所有権の確認が成功し、サイトマップ送信が完了、URL検査でクロール促進できる状態になります。 補足 この記事は HTMLファイルアップロード方式 で所有権確認を行い、サイトマップ登録・URL検査・運用の要点までを扱います。 🧭 前提：サイト種別とURL構成 本文着手前に、GitHub Pagesのサイト種別と公開URLを正しく把握します。これがSearch Consoleのプロパティ設定とbaseURL整合の土台になります。 操作 自サイトが ユーザーサイト か プロジェクトサイト かを確認する ユーザーサイト：https://username.github.io/ プロジェクトサイト：https://username.github.io/repository-name/ 目的 Search Console登録方式（URL プレフィックス）と、HugoのbaseURL/内部リンク/画像パス/OGPを公開URLに合わせて一貫させる。 前提 GitHub Pagesの公開設定が済んでいる（ユーザーサイト or プロジェクトサイト） 結果（この時点でできること） 以降の設定で、URL不一致による所有権確認失敗やサイトマップ404を回避できる。 注意 プロジェクトサイトは公開パスが/repository-name/ を含みます。Search ConsoleのURLプレフィックス、検証ファイルURL、サイトマップURLの末尾スラッシュとサブパスが一致しているか、常に確認しましょう。 補足：サイト種別の早見表 ユーザーサイト：https://username.github.io/（サブパスなし） プロジェクトサイト：https://username.github.io/repository-name/（サブパスあり） 🧩 前提条件の確認（Hugo設定） Search Console導入前に、Hugoの基本SEO設定（robots.txt と sitemap）を整えます。 操作 hugo.yaml（またはconfig.toml）に以下の設定を追加/確認 目的 robots.txt と sitemap.xml を自動生成し、クロールとインデックスの土台を作る。 前提 ...

このガイドのゴール：Hugo + PaperMod を使ったブログを GitHub Pages に公開し、以降は記事を push するだけで自動更新できる状態にする。 ✅ 前提条件（必要な環境） Git と Hugo（Extended版） をインストール済み GitHubアカウントを保有 コマンドラインが使える（macOS/Linux/WSL いずれもOK） Extended版が必要な理由：PaperModなど一部テーマはSCSSのコンパイルにExtended版を使います。 🛠️ Hugoサイトの新規作成 hugo new site blog --format yaml # 新規Hugoサイト（設定ファイルをYAMLで作成） cd blog git init # Gitリポジトリを初期化 🎨 PaperModテーマの導入 最も簡単なのは Git Submodule でテーマを取り込む方法です。 git submodule add --depth=1 https://github.com/adityatelange/hugo-PaperMod.git themes/PaperMod hugo.yaml にテーマを指定します： theme: ["PaperMod"] 注意：GitHub Actions でビルドする際は actions/checkout の submodules: true を必ず設定してください（後述）。 代替案：Hugo Modulesでテーマを管理する方法もあります（hugo mod init → module.importsにPaperModを指定）。慣れるまではSubmoduleが分かりやすいです。 📝 Hugoの基本設定（hugo.yaml） 最低限の設定例を示します。後から拡張できます。 baseURL: "https://username.github.io/blog/" # 後で必ず自分の公開URLに合わせて変更 languageCode: "ja-jp" title: "My Hugo Blog" theme: ["PaperMod"] paginate: 10 outputs: home: ["HTML", "RSS", "JSON"] params: defaultTheme: "auto" # ダーク/ライト切替 ShowShareButtons: true ShowReadingTime: true ShowCodeCopyButtons: true showtoc: true # 記事内目次 images: ["images/og-image.png"] # OGP用 author: "HNEST" menu: main: - identifier: archives name: Archives url: /archives/ weight: 10 - identifier: tags name: Tags url: /tags/ weight: 20 ✍ 初回記事の作成とローカル確認 記事を作成します： ...