ひらがな・カタカナ・漢字のどの表記で書くかは、「読者が実際に検索している表記」と「検索結果で同じ意味として扱われているか」を確かめて決めるのが基本です。この記事では、表記ごとの検索のされ方を調べる方法、タイトル・見出し・本文での表記の決め方、表記ゆれを防ぐ運用ルール、そして WordPress のサイト内検索で表記の違いを吸収する方法までを説明します。
表記の違いは検索でどう扱われるか
Google は日本語の文章を単語に区切って理解し、同義語や表記の違いもある程度は同じ意味として扱います。「りんご」「リンゴ」「林檎」のように、表記が違っても似た検索結果が返ってくることは珍しくありません。
一方で、表記によって検索結果が大きく変わる言葉もあります。たとえばカタカナ表記が特定の商品名・サービス名を指し、ひらがな表記が一般的な意味を指す場合です。検索エンジンが「表記が違えば検索意図も違う」と判断している言葉では、表記の選択が、どの検索結果に表示されやすいかに関わります。
このため、「ひらがなが有利」「カタカナが有利」という一般的な正解はありません。言葉ごとに調べて判断する必要があります。また、すべての表記を本文に詰め込む方法は、読みにくくなるうえ、Google がスパムに関するポリシーで挙げている「キーワードの乱用」に近づくため避けてください。
手順1：読者が使っている表記を調べる
まず、表記ごとにどれくらい検索されているか、自分のサイトにどの表記で流入しているかを確認します。
- Search Console の検索パフォーマンス：検索キーワードの絞り込みで、「クエリを含む」に各表記を入れて比較します。すでに記事がある場合、実際に表示・クリックされている表記がわかります。
- Google トレンド：複数の表記を並べて比較すると、相対的な関心の大きさや、季節・年代による違いを見られます。
- キーワードプランナーや各種キーワードツール：表記別の検索ボリュームの目安を確認できます。ツールによっては表記の違いをまとめて集計するため、数値がまったく同じになる場合は「区別されていない」可能性を考えます。
- 検索窓のサジェストと関連キーワード：入力途中に出る候補から、よく一緒に検索される語と表記の傾向がわかります。
数値はツールごとに集計方法が異なり、時期によっても変わります。ここで挙げたツールの画面や機能も変更されることがあります（2026年10月現在）。一つのツールの数字だけで決めず、傾向として読み取ってください。
手順2：表記ごとの検索結果を比較する
次に、候補の表記それぞれで実際に検索し、上位に表示されるページを比べます。ログイン状態や地域の影響を減らすため、シークレットウィンドウを使うと比較しやすくなります。
- 上位のページがほぼ同じ：検索エンジンは同じ意味として扱っています。読者にとって自然で、検索数が多い表記を主に使えば十分です。
- 上位のページが大きく違う：表記ごとに検索意図が分かれています。自分の記事が答えたい意図に合う表記を選びます。両方の意図に応えたいなら、無理に1記事にまとめず、記事を分けることも検討します。
- 一部だけ違う：主な表記を決めたうえで、別の表記を本文の自然な位置に入れておく方法が向いています。
手順3：タイトル・見出し・本文で表記を決める
調査結果をもとに、記事内での表記を決めます。
タイトルと見出しには、主に使う表記を一つ選んで入れます。「りんご（リンゴ・林檎）の保存方法」のように、すべての表記を並べるタイトルは読みにくく、検索結果でも不自然に見えます。Google は検索結果のタイトルを、ページの内容に合わせて書き換えて表示することもあるため、タイトルの表記で表示を細かく制御しようとするより、内容とタイトルを一致させることを優先してください。
本文では、初出で「りんご（林檎）」のように別表記を補うと、読み方や意味が伝わりやすくなり、別の表記で探していた読者にも内容が一致していることが伝わります。その後は主に使う表記で統一します。難しい漢字や固有名詞の読みを示したいときは、HTML の <ruby> 要素でふりがなを付ける方法もあります。
<p><ruby>林檎<rp>（</rp><rt>りんご</rt><rp>）</rp></ruby>は冷蔵庫の野菜室で保存します。</p>画像の代替テキストやメタディスクリプションも、本文と同じ表記ルールに合わせます。メタディスクリプションは検索結果にそのまま使われるとは限りませんが、表記がそろっていると記事全体の印象が整います。
手順4：表記ゆれを防ぐ運用ルールを作る
複数人で記事を書くサイトや、記事数が多いサイトでは、表記ゆれが起きやすくなります。「サーバー」と「サーバ」、「ユーザー」と「ユーザ」のように、同じサイト内で表記が混在すると、読者が迷うだけでなく、サイト内検索や内部リンクの設計にも影響します。
次のような表記ルール表を作り、執筆者全員で共有しておくと防ぎやすくなります。
- 主に使う表記と、使わない表記（例：サーバー／×サーバ）
- 外来語の長音の扱い。マイクロソフトが2008年に製品の表記を「サーバー」のように語尾の長音を付ける方針に変えたように、一般的な表記は時代で変わります。迷ったら、読者層がよく目にする表記に合わせます
- 数字・英字の全角／半角、送り仮名の基準
既存の記事を一括で直す前には、データベースのバックアップを取ってください。WP-CLI の wp search-replace は --dry-run を付けると件数だけを確認できます。ただし、単純な置換は「サーバ」が「サーバー」の一部にも一致するなど意図しない箇所まで変えてしまうため、件数を見て対象を確かめてから、記事を目視で直す方が安全です。
手順5：サイト内検索で表記の違いを吸収する
WordPress 標準のサイト内検索は、入力された文字列をそのまま含む投稿を探す仕組みです。読者が「りんご」で検索しても、本文が「リンゴ」だけの記事は見つかりません。
サイト内検索の改善には、同義語の設定機能を持つ検索プラグイン（Relevanssi など）を使う方法があります。機能の範囲や無料版・有料版の違いは変わることがあるため、導入前に公式の説明を確認してください。
プラグインを使わずに、ひらがなとカタカナの違いだけを吸収したい場合は、posts_search フィルターで検索条件を追加する方法があります。PHP の mb_convert_kana() で、入力された語のカタカナ版とひらがな版を作り、どれかを含む投稿を検索対象にします。
<?php
// 子テーマの functions.php か mu-plugin に記述（ステージングで動作確認してから本番へ）
add_filter( 'posts_search', 'wpdr_kana_variant_search', 10, 2 );
function wpdr_kana_variant_search( $search, $query ) {
global $wpdb;
if ( is_admin() || ! $query->is_main_query() || ! $query->is_search() || '' === $search ) {
return $search;
}
if ( ! function_exists( 'mb_convert_kana' ) ) {
return $search;
}
$term = trim( (string) $query->get( 's' ) );
if ( '' === $term || mb_strlen( $term, 'UTF-8' ) > 50 ) {
return $search;
}
// C: ひらがな→カタカナ、c: カタカナ→ひらがな
$variants = array_unique( array(
mb_convert_kana( $term, 'C', 'UTF-8' ),
mb_convert_kana( $term, 'c', 'UTF-8' ),
) );
$variants = array_diff( $variants, array( $term ) );
if ( empty( $variants ) ) {
return $search;
}
$clauses = array();
foreach ( $variants as $variant ) {
$like = '%' . $wpdb->esc_like( $variant ) . '%';
$clauses[] = $wpdb->prepare(
"({$wpdb->posts}.post_title LIKE %s OR {$wpdb->posts}.post_content LIKE %s)",
$like,
$like
);
}
$extra = implode( ' OR ', $clauses );
// 標準の検索と同じく、未ログイン時はパスワード保護の投稿を除外する
if ( ! is_user_logged_in() ) {
$extra = "( ( {$extra} ) AND {$wpdb->posts}.post_password = '' )";
}
// 元の検索条件と OR で結ぶ
$original = preg_replace( '/^\s*AND\s+/', '', $search );
return " AND ( ( {$original} ) OR {$extra} ) ";
}入力値は $wpdb->esc_like() と $wpdb->prepare() を通してから SQL に入れています。このコードには次の制限があります。
- 変換するのは、ひらがなとカタカナの違いだけです。漢字表記（林檎など）や「サーバ／サーバー」の違いは吸収できません
- スペースで区切った複数語の検索では、全体を一つの文字列として変換するため、追加条件がほとんど一致しません
LIKEによる検索のため、記事数が多いと処理が重くなります
漢字表記まで含めて吸収したい場合や、記事数が多い場合は、同義語辞書を持つ検索プラグインや外部の検索サービスを検討してください。
まとめ
- 表記の有利・不利は言葉ごとに違うため、検索数と実際の検索結果を表記別に調べて判断する
- 検索結果がほぼ同じなら自然で検索数の多い表記に統一し、大きく違うなら意図に合う表記を選ぶ。必要なら記事を分ける
- タイトルと見出しは主に使う表記を一つにし、本文の初出で別表記を補う。表記を詰め込まない
- 表記ルール表を作って表記ゆれを防ぎ、一括置換はバックアップと件数確認のうえで慎重に行う
- サイト内検索は標準では表記の違いを吸収しないため、プラグインか
posts_searchフィルターで補う