SEO Web開発自分用メモ

SEOとWebツール戦略を実践した日 — 2026-06-28の記録

2026-06-28 · SEADICE · 自分向け学習記録

これは自分向けの学習記録。後で見返せるように実践から得た気づきをまとめておく。

今日やったこと（サマリー）

Webツール作成

ブログ記事作成

トップページSEO刷新

今日は「ツールを作って、関連記事3本で囲む」というSEO戦略を実際にやってみた。

営業日カウンター（/apps/eigyobi/）を作成 → 関連記事3本
コンパニオンプランツ相性診断（/apps/companion/）を作成 → 関連記事3本
トップページのコンセプト・テキストを全面見直し

学んだこと1：「ツール型検索意図」を狙う

ツール型検索意図とは、ユーザーが記事ではなく計算・診断・変換の結果そのものを求めている検索ニーズです。ここにツールを置けば検索意図と完全一致します。

背景にある問題意識

「普通の記事を書いても埋もれる」というのは今日最初に考えたこと。AIで検索できる時代になると、情報を書いても差別化できない。GoogleもAI Overviewで答えを出してしまう。

そこで気づいたのが「ツール型検索意図」というジャンルの存在だ。

気づき

「3営業日後いつ」「トマト一緒に植えてはいけない野菜」のような検索は、ユーザーが答えを計算・診断してほしいのであって、記事を読みたいわけじゃない。このニーズに対して「記事しかない」ジャンルが存在する。そこにツールを置くと検索意図と完全一致する。

ツール型検索意図の特徴

検索者はアクションを起こしたい（計算したい・診断したい・変換したい）
テキストで説明されても面倒 → インタラクティブなツールの方が満足度が高い
滞在時間が長くなる（ツールを操作するため）
ブックマーク・再訪率が高い
競合が「記事しかない」ジャンルを見つければブルーオーシャン

今日選んだジャンル

ツール	検索意図	競合状況
営業日カウンター	「3営業日後いつ」「N営業日後計算」	電卓サイトがあるが、祝日対応・タブ切替などUXが弱い
コンパニオンプランツ相性診断	「トマト一緒に植えていい野菜」「コンパニオンプランツ相性」	記事はあるがインタラクティブなツールが少ない

学んだこと2：ツール + 記事3本の相互内部リンク構造

なぜ記事3本なのか

ツールを作るだけでは「このドメインにこのテーマがある」とGoogleに伝える信号が弱い。関連する記事を複数作ることでテーマ権威性（Topical Authority）を積み上げる。

テーマ権威性 = 「このサイトはこのテーマに詳しい」とGoogleが判断すること。特定テーマについて複数のコンテンツを持つサイトは、単発の記事より上位表示されやすい。

内部リンクの構造

今日実装した構造はこう：

ツールページ（/apps/eigyobi/）
  └── 関連記事へのリンク × 3
      ├── /blog/eigyobi-kazoekata/    ← 3営業日の数え方
      ├── /blog/eigyobi-obon-nenmatsu/ ← お盆・年末の営業日
      └── /blog/eigyobi-shiharai/     ← 支払い期限と営業日

各記事
  └── ツールへのCTAボタン（2箇所）
      「営業日計算ツールを使う →」

ツール → 記事（読み込み）、記事 → ツール（回遊・使用）というサイクルを作る。

重要

内部リンクのCTAは記事の冒頭と末尾の2箇所に設置した。冒頭は「ツールがあること」を先に伝えて興味を引き、末尾は「記事を読んで納得したうえで使う」という流れを作る。どちらか1箇所だけだとCTR（クリック率）が下がる。

記事のキーワード選び方

記事を書くときは「ツール名で検索する人が次に何を調べるか」から逆算した：

「営業日計算」→「3営業日の数え方当日含む？」（実際によく混乱するポイント）
「営業日計算」→「お盆年末年始営業日」（特定時期の疑問）
「コンパニオンプランツ相性」→「一緒に植えてはいけない組み合わせ」（NG情報は強い）

学んだこと3：FAQ 10問 + JSON-LD FAQPage = 強調スニペット狙い

強調スニペット（Featured Snippet）とは

Googleの検索結果で1位より上に表示される「ゼロ位置」のこと。FAQだと検索結果でアコーディオンで展開される形式（「People Also Ask」）になる。

実装したこと

ツールページにFAQ 10問以上を設置し、JSON-LD（構造化データ）の FAQPage スキーマを実装した。

<script type="application/ld+json">
{
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "3営業日後はいつ？",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "月曜日起算の場合、3営業日後は木曜日になります..."
      }
    },
    ...
  ]
}
</script>

FAQ設計のポイント

ポイント	理由
10問以上書く	Googleは複数のFAQを取得して表示する。少ないと強調スニペット候補に漏れる
質問文を「〜は何ですか？」「〜はいつですか？」形式に	検索クエリの語尾パターンに合わせることで一致率が上がる
回答に具体的な数値・例を入れる	「木曜日になります」より「月曜起算なら木曜、金曜起算なら翌々週の金曜になります」の方がスニペットとして引用されやすい
HTMLのFAQとJSON-LDを一致させる	不一致があるとGoogleがスパムとみなすリスクがある

学んだこと4：JSON-LD の細かいポイント

Organization vs Person

サイト管理者のスキーマを最初 "@type": "Person" にしていたが、ビジネス・スタジオとして運営するなら "@type": "Organization" の方が適切。

Person：個人ブロガー・フリーランス個人向け
Organization：スタジオ・会社・ブランドとして運営する場合

SEADICE は個人スタジオだが「Organization」にした。Googleがサイトをブランドとして認識しやすくなる。

WebApplication スキーマ（ツールページ）

ツールページには WebApplication スキーマを使う。無料ツールなら offers に price: 0 を入れておく：

{
  "@type": "WebApplication",
  "name": "営業日計算ツール",
  "applicationCategory": "UtilitiesApplication",
  "operatingSystem": "Web",
  "offers": {
    "@type": "Offer",
    "price": "0",
    "priceCurrency": "JPY"
  }
}

「無料」という情報が検索結果に表示されるようになる（リッチリザルト）。

BreadcrumbList

パンくずリストのスキーマ。これを入れると検索結果のURLがドメインだけでなく「ホーム / ブログ / 記事名」という階層で表示される。クリック率向上に効く。

{
  "@type": "BreadcrumbList",
  "itemListElement": [
    { "@type": "ListItem", "position": 1, "name": "ホーム", "item": "https://seadice.win/" },
    { "@type": "ListItem", "position": 2, "name": "ブログ", "item": "https://seadice.win/blog/" },
    { "@type": "ListItem", "position": 3, "name": "記事名", "item": "https://seadice.win/blog/xxx/" }
  ]
}

@graph でまとめて書く

複数の構造化データは @graph 配列にまとめて1つの <script> タグに書けば整理しやすい：

{
  "@context": "https://schema.org",
  "@graph": [
    { "@type": "BlogPosting", ... },
    { "@type": "BreadcrumbList", ... },
    { "@type": "FAQPage", ... }
  ]
}

学んだこと5：画像の読み込み速度と SEO

fetchpriority="high"

ファーストビューのヒーロー画像に fetchpriority="high" を追加した。これはブラウザに「この画像を優先して読み込め」と伝えるヒント。LCP（Largest Contentful Paint）のスコアに直結する。

<img src="/icons/seadice_hero.webp"
     alt="..."
     width="400" height="300"
     fetchpriority="high"
     decoding="async">

ファーストビュー画像にだけ使う。他の画像には loading="lazy" を使う（同時に指定しない）。

WebP 変換

すべての表示画像はWebPに変換した。コマンド：

cwebp -q 85 input.png -o output.webp

PNGに比べて30〜50%ファイルサイズが小さくなる。OGP画像（SNSシェア用）はPNGのまま（WebPは一部SNSで対応していない）。

学んだこと6：コンセプトの変更

変更前 → 変更後

	変更前	変更後
ターゲット	忙しい個人事業主・中小企業	日常生活・ニッチなジャンルのユーザー全般
価値提案	業務をAIで自動化	AIと自動化で生活をもっと快適に
ABOUTカード	業務効率化系	ニッチなニーズに応える / AIで自動化 / ユーザーファースト

なぜ変更したか

「個人事業主・中小企業向け」というポジションは競合が多い。SaaS系・業務ツール系のサービスが既にたくさんある。一方、「日常生活のちょっとした不便を解決するニッチツール」は競合が少ない。

考え方

「家庭菜園の相性診断」「営業日カウンター」「iOS画像リサイズ」——これらは業務ツールじゃないが、ちゃんとした需要がある。ニッチなジャンルを積み重ねていく方がSEO的にも差別化的にも戦いやすい。

学んだこと7：apps-pipeline とミニアプリの関係

現状の構造

毎朝自動でFlutterアプリが生成される apps-pipeline がある。その出力先として「ミニアプリ」セクション（旧「無料Webツール」）が位置づけられている。

今日気づいたのは「ミニアプリ」というラベルのミスマッチ。自動生成のFlutterアプリが並ぶセクションに「無料Webツール」は合わない。「ミニアプリ集」に変更した。

セクション名の整理

セクション	変更前	変更後	中身
手動で作るWebツール	Web Apps	Web Tools	営業日カウンター、コンパニオンプランツ相性診断など
自動生成Flutterアプリ	無料Webツール	ミニアプリ集	apps-pipelineの出力

今後のアクション

sitemap.xml に今日作ったページを全部追加する（後回しにしてる）
Google Search Console でサイトマップを再送信する
コンパニオンプランツ関連で記事をさらに追加（「トマトの育て方とコンパニオンプランツ」など）
家庭菜園アプリ（kateisaien）のWebバージョンをリリースする（iOS審査中）
営業日カウンターの計算精度をさらに上げる（半日・時間計算など）
tikdog アプリのWebページを追加する

今日の総括

「Webサイトを作っても埋もれる」という問題意識から始まり、「検索意図がツール型なのに記事しかないジャンル」を狙うという方向性に辿り着いた。実際に2つのツールと6本の記事を1日で作り切った。

大事なのは「ツールを作って終わり」じゃなくて、ツール × 記事 × 内部リンクという三角形を作ること。この三角形が1セットできると、Googleから見て「このサイトはこのテーマに詳しい」と認識されやすくなる。

コンパニオンプランツのようなニッチなジャンルは、SEOで上位を取れれば独占できる。継続して積み重ねていこう。

← ブログ一覧に戻る