WordPressテーマHuemanで見出しが薄い灰色に見える場合、まず「テーマの仕様」「見出し内リンク」「親要素の透明度」「追加CSSの競合」のどれかを切り分けます。昔のHuemanでは見出し内のspanなどに淡い色が指定される例がありましたが、現在の版や子テーマ、プラグインでHTMLとCSSは変わります。古いセレクターをそのまま貼るのではなく、ブラウザーの開発者ツールで実際に効いている規則を特定してから修正してください。
テーマ本体のstyle.cssを直接編集しないことが最重要です。更新で上書きされるため、外観の追加CSS、子テーマ、またはテーマが提供する色設定を使います。
薄く見える原因を確認する
見出し全体が薄いのか、一部の文字だけ薄いのか、リンクを含むときだけ薄いのかを確認します。投稿編集画面では濃いのに公開画面だけ薄い場合は、テーマ側CSSの可能性が高いです。公開画面でも特定記事だけなら、ブロックに設定した文字色、カスタムHTML、貼り付けたインラインスタイルを疑います。
Huemanのテーマページで現在の版と更新日を確認し、WordPress本体、PHP、子テーマとの互換性を調べます。スクリーンショットだけで色コードを決めず、Computed(計算済み)スタイルでcolor、opacity、filter、text-shadow、背景色を確認します。文字色のコントラストは背景との組み合わせで決まるため、色だけでなくフォントの太さと大きさも見ます。
開発者ツールで効いているCSSを探す
- 問題が見える公開ページを、ログアウト状態でも開きます。キャッシュの影響を減らすため別ブラウザーでも確認します。
- 見出し文字を右クリックして「検証」を開き、h2、h3、a、spanなど実際に色が付く要素を選択します。
- StylesとComputedでcolorを探し、どのCSSファイルの何行が最終的に採用されたかを記録します。
- 開発者ツール上で一時的に色を変更し、本文、リンク、ホバー、ダーク背景など他の状態も読みやすいか確認します。
- 候補セレクターを必要な記事領域へ絞り、追加CSSへ移します。公開前に現在のCSSをテキストでバックアップします。
たとえば見出し内のspanだけが薄い場合、`.entry h2 span`のような対象が見えるかもしれません。しかしテーマ版によってクラス名は違います。`h2 { color: … !important; }`のように全サイトへ強く上書きすると、フッターやウィジェット、管理用ブロックまで変わるため避けます。まず投稿本文のラッパークラスと見出しレベルを組み合わせて範囲を限定します。
追加CSSで直す例
次は考え方を示す例です。実サイトの検証結果に合わせてセレクターと色を調整してください。テーマやプラグインが別のクラスを使う場合は効きません。本文背景が白に近い想定で、濃い文字色へ統一しています。
.entry-content h2,
.entry-content h2 span {
color: #263238;
}
.entry-content h2 a {
color: inherit;
text-decoration-thickness: 0.08em;
}
最初は`!important`を付けずに試します。効かない場合は、CSSの読み込み順、元のセレクターの詳細度、インラインスタイルを調べます。強制指定を重ねると後の保守が難しくなるため、元の規則に近い範囲で詳細度を調整します。リンク色をinheritにする場合は、リンクであることが下線や別の視覚表現でも分かるようにします。
どこへCSSを保存するか
Huemanはクラシックテーマとして提供されているため、多くの環境では「外観 → カスタマイズ → 追加CSS」を使えます。WordPress公式資料では、追加CSSはテーマファイルを直接編集せずに外観を調整する手段です。WordPressの版やサイトエディター対応状況で画面の場所は変わるので、外観メニューと公式ドキュメントを確認してください。
テーマを切り替えると、そのテーマに紐づく追加CSSが現在の表示へ使われなくなることがあります。テーマ変更前にCSSをエクスポートし、新テーマで必要な規則だけを移植します。長期的にテンプレート構造や複数ファイルを変更するなら子テーマが適しています。子テーマでも、親テーマ更新後にセレクターやHTML構造が変わる可能性があるため回帰確認が必要です。
アクセシビリティを含めた確認
- 本文背景と見出し文字のコントラストが十分で、低輝度画面でも読める
- 見出し内リンクが色だけでなく下線やホバー・フォーカス表示でも識別できる
- スマートフォン、タブレット、PCで折り返しや行間が崩れない
- h2、h3、h4の階層が見た目だけでなくHTML上も論理的になっている
- ダークモード系プラグインや高コントラスト設定でも文字が背景へ溶け込まない
色の最終判断は代表ページだけでなく、通常記事、固定ページ、カテゴリ、検索結果、404、コメント、ウィジェットでも行います。見出しの装飾に疑似要素を使っている場合、色変更で線やアイコンとのバランスが崩れることがあります。キーボードでリンクへフォーカスしたときの枠も消さないでください。
キャッシュと反映されない問題
追加CSSを保存しても変わらない場合、WordPressキャッシュ、CDN、ブラウザーキャッシュ、最適化プラグインが古いCSSを配信していることがあります。最初にページソースまたはNetworkで新しい規則が配信されているか確認し、変更対象のキャッシュだけを消します。全キャッシュ削除を何度も行うと負荷が上がるため、保守時間とアクセス量を考慮します。
CSS結合・縮小を一時的に切り替える場合は現在値を記録し、検証後に元へ戻します。表示速度対策の設定を恒久的に無効化するのではなく、問題となるファイルの除外や生成キャッシュの再構築を検討します。
ロールバック手順
変更前の追加CSSを日時付きテキストとして保存し、変更した規則だけを別ブロックにまとめます。表示崩れ、リンク識別不能、他ページへの影響が出たら、そのブロックを削除して保存し、関連キャッシュを一度だけ更新します。テーマファイルを既に直接編集している場合は、公式配布版と差分を取り、必要な変更を子テーマまたは追加CSSへ移してから親テーマを正常な状態へ戻します。
見出しが薄い原因がテーマではなく記事内のインライン色なら、記事を一括置換する前に数件で確認します。投稿リビジョンやデータベースバックアップを確保し、ブロック設定を使って修正する方が安全です。原因を特定し、最小範囲で直し、複数画面で確認することが、更新に強い解消方法です。
テーマ更新前後の回帰テスト
HuemanやWordPressを更新する前に、追加CSSの全文、テーマ設定、代表ページのスクリーンショットを保存します。ステージングで更新し、見出しだけでなく本文リンク、引用、表、リスト、コード、ウィジェット、コメントの色を比較します。CSSファイル名にキャッシュ用の版が付く場合、開発者ツールで更新後のファイルが実際に配信されているかを確認します。
更新で元の不具合が解消されていたら、過去の上書きCSSが新しいデザインを妨げることがあります。追加規則を一つずつ無効にして影響を確認し、不要なものを削除します。変更理由をコメントで残す場合も個人情報や内部URLを書かず、対象テーマ版と確認日を記載すると後任が判断しやすくなります。

コメント