WordPress予約投稿のタイトル・スラッグ重複を検査する方法

WordPress予約投稿のタイトル・スラッグ重複を検査する方法

WordPressの予約投稿では、タイトルが完全一致していなくても内容が重複することがあります。反対に、似た単語を使っていても対象読者と結論が違えば、別記事として役割を分けられます。

2026年7月30日の二回目の補充前、このサイトには公開469件、予約4件、下書き34件がありました。計507件を全状態から取得し、タイトル、スラッグ、検索意図を比較してから候補を選びました。その検査方法を説明します。最終確認日:2026年7月30日

俺のクマ

タイトルが一文字でも違えば重複ではないクマ?

大明司一利

文字列だけでなく、読者、結論、見出し、独自情報まで比べよう。タイトル違いの同じ記事を止められるよ。

具体的なチェック手順は、全状態の取得、文字列比較、検索意図の六項目比較、保存後の再取得です。例えばタイトル類似度が低くても、読者と結論が同じなら内容重複として止めます。

  • タイトルの完全一致と類似度
  • スラッグの一意性
  • 検索意図の六項目
  • 保存後の全状態再検査

公開・予約・下書きの全状態を取得する

重複検査では公開済みだけを見ません。futureに同じテーマが待っている場合や、別のdraftが先に同じ検索意図を扱っている場合があるためです。

状態ごとに全ページを取得する

WordPress REST APIのPosts公式資料に従い、publish、future、draft、pending、privateを状態別に取得します。一ページの上限を超えるサイトでは、レスポンスヘッダーの総ページ数まで巡回します。

取得項目は投稿ID、status、title、slug、date、content、カテゴリー、タグです。認証付きのedit contextを使い、下書き本文も比較できる範囲で取得します。

投稿IDを比較記録の主キーにする

同じタイトルが複数あっても区別できるよう、判定は投稿ID単位で残します。自分自身の投稿を比較対象から除外しないと、常に完全一致として誤検出します。

今回の候補では、更新対象IDを除外した506件と新タイトルを比較しました。タイトル変更前の旧題もバックアップへ保存し、判断経緯を追えるようにしました。

タイトルとスラッグを正規化して比較する

見た目が同じでもHTML実体参照や空白が違うことがあります。タグを除去し、文字参照を戻し、連続空白を一つへそろえてから比較します。

完全一致と類似度を分けて検査する

正規化後の完全一致は即時停止します。次に文字列類似度を計算し、一定値以上の候補を人が検索意図まで確認します。

類似度は重複の証明ではありません。長い共通語を含むだけで高くなる場合があるため、候補を絞るフィルターとして使います。

スラッグは全状態で一意か確認する

下書きでも既に同じスラッグを持つ投稿がある可能性があります。新スラッグを全状態と比較し、同じものがあれば別案へ変えます。

公開済みURLの変更は、下書きの予約とは別の高リスク作業です。既存公開記事のスラッグを重複回避のために変更せず、新しい下書き側だけを調整します。

検索意図の六項目で内容重複を確認する

文字列検査を通った後、メインキーワード、想定読者、結論、H2構成、紹介対象、独自情報の六項目を比較します。

三項目以上の重なりを停止条件にする

六項目のうち三項目以上が既存記事と重なる場合は、そのまま予約しません。対象を狭める、別の判断を示す、独自データを加えるなど、役割を明確に分けられるか確認します。

ツール名だけをChatGPT、Gemini、Claudeへ置き換え、読者と結論が同じ記事は典型的な統合候補です。タイトル類似度が低くても内容重複として止めます。

記事固有の疑問を一文にする

今回の記事なら『507件ある全状態から、予約候補のタイトル・スラッグ・検索意図の重複を検査したい』が固有の疑問です。一般的なAI記事の始め方とは役割が違います。

一文にできない候補は検索意図が広すぎます。記事を作る前に対象読者と読み終えた後の判断を決め、既存記事との差を説明できるようにします。

品質条件を通した候補だけ不足日へ割り当てる

重複がないだけでは予約できません。本文構造、一次情報、SEO、吹き出し、リンク、画像担当、復元可能性も確認します。

不足日の早い順に日時を割り当てる

翌日からの連続予約を数え、最初の空白日から候補を割り当てます。今回の二回目は8月4日、5日、6日の順で、既存の9時枠が空いていることを確認します。

遠い日へ先に入れると直近の停止耐性が上がりません。一回最大三件に区切り、三件の保存後に連続日数を再計算します。

記事ごとにguardとバックアップを作る

一件ごとに投稿ガードを実行し、外部LLM API無効、future、実保存、自動予約を確認します。変更前の投稿データは投稿ID別JSONとしてバックアップします。

バックアップには本文、状態、日時、タイトル、スラッグ、カテゴリー、タグ、旧featured_mediaを含めます。認証情報は保存しません。

保存後のREST再取得で重複と状態を監査する

WordPressへ保存した後、同じ投稿IDと全状態を再取得します。保存前に空いていたスラッグが、並行処理で使われていないかも再確認します。

本文・SEO・日時を計画と照合する

status=future、予約日時、タイトル、スラッグ、本文ハッシュ、カテゴリー、タグを照合します。Rank Mathの固有フォーカスキーワード更新も記事別に成功を記録します。

一項目でも不一致なら対象記事だけ下書きへ戻し、残る不足日として再計算します。HTTP成功や終了コードだけで予約完了にしません。

画像と連続予約日数まで確認する

担当ボットでWebPを設定し、記事のfeatured_media、メディアID、image/webp、.webp URL、画像実体を確認します。旧画像は削除しません。

Googleの人を第一に考えたコンテンツの公式資料でも、既存情報の要約だけでなく独自情報や十分な価値があるかを確認するよう示されています。文字列検査と検索意図の比較を組み合わせることが、予約在庫を重複記事で埋めないための要点です。