【PR】この記事には広告リンクが含まれています。
WordPressの内部リンクを原稿ごとに手入力すると、まだ公開されていないURL、変更前のslug、削除済みページ、別記事のURLが混ざりやすくなります。自動投稿では、本文を作る前に公開済み記事の台帳を読み、利用可能なURLだけを候補として渡す方が安全です。
運営者の環境ではWordPressとSWELLをエックスサーバーで運用し、Apps Scriptからの自動公開を確認済みです。週4本の処理では、各記事の公開URL、status、本文、slug、featured_mediaを個別に確認するまで完了扱いにしません。この確認結果を内部リンク台帳へ戻す流れを説明します。
最初に確認したい結論
- 記事IDを全タブ共通キーとしてURLとslugを管理する
- status=publishとHTTP 200を確認した記事だけを候補にする
- アンカーテキストとリンク先の検索意図を一致させる
- 公開前URLや推測したslugを本文へ入れない
- 公開後に本文HTMLを再取得して内部リンクを検査する
- URL変更や非公開化の影響記事を台帳から逆引きする
記事IDを正本にする
タイトルは改善やリライトで変わるため、タイトル文字列だけをキーにすると同じ記事を追いにくくなります。記事ID、WordPress投稿ID、slug、公開URLを別の列で持ちます。
管理表の他タブも記事IDでつなげれば、記事制作プラン、下書き、公開結果、リライト履歴から同じ投稿を参照できます。タイトル変更で内部リンク関係が切れません。
公開済みURLだけを候補にする
候補条件は記事マスターの公開済み表示だけでは不十分です。WordPress REST APIから投稿を再取得し、status=publish、slug、link、content、featured_mediaを確認します。
さらに公開URLへアクセスしてHTTP 200を確認します。管理表とWordPressのどちらか一方だけが公開済みでも、照合が終わるまで内部リンク候補へ出しません。
台帳へ残す列
内部リンクID、リンク元記事ID、リンク先記事ID、主要キーワード、アンカーテキスト、設置位置、状態、公開URL、確認日、確認内容を持ちます。
リンク元とリンク先を両方の記事IDで残すと、URL変更や非公開化が発生した際に、修正対象の記事を一覧で抽出できます。アンカーテキストの重複や偏りも確認できます。
HYPERLINK関数と実URLを分ける
Google SheetsのHYPERLINK関数は、URLと表示ラベルを分けてセル内リンクを作れます。ただし、見た目のラベルだけでは本文へ挿入すべき実URLを取得できません。
台帳には機械処理用の生URL列と、人が確認する表示リンク列を分けます。Apps Scriptは生URL列を読み、人は表示ラベルからページを開いて内容を確認します。
検索意図で選ぶ
同じ単語を含む記事でも、読者が次に知りたい内容とずれていれば内部リンクとして役立ちません。リンク元の段落、リンク先の結論、主要キーワードを比較します。
関連記事を数だけ増やさず、本文の説明を補う記事、次の実務へ進む記事、具体例を示す記事を選びます。一つの段落へ過剰にリンクを並べません。
アンカーテキストを固定し過ぎない
常に記事タイトル全文を使うと文章が長くなり、同じ表現が繰り返されます。一方で『こちら』だけではリンク先が分かりません。
リンク先の内容が分かる短い表現を使い、誇張や未掲載内容を含めません。台帳へ実際のアンカーを残し、リンク先タイトル変更後も意味が通るか確認します。
公開順序を考える
新規4本を同時に公開する場合、まだ公開されていない同週記事を相互リンクすると、先に公開された記事から一時的に404へつながる可能性があります。
既公開記事だけを初期内部リンクに使い、同週記事同士のリンクは4本の公開確認後に追加するか、更新処理として別に管理します。公開順への依存を本文生成から外します。
WordPress保存後の検査
原稿内URLが正しくても、HTML変換や置換処理で末尾の記号、引用符、相対URLが変わることがあります。保存後本文からa要素を抽出し、hrefを正規化して台帳と比較します。
自サイトドメインのリンクだけを内部リンクとして数え、プロフィールや固定ページ、画像URLを記事間リンクと混同しません。リンク切れだけでなく、リンク先記事IDとの一致も確認します。
公開後のHTTP確認
内部リンク先がHTTP 200でも、別ページへリダイレクトされている場合があります。最終URLと想定URL、ページタイトル、本文の主題を確認します。
アクセス拒否や一時的な5xxは即座にURL削除せず、限定再試行して通信障害か恒常的な問題かを分けます。失敗記事だけを修正対象にします。
リライト時に同じURLを維持する
公開済み記事の改善は同じ記事ID、投稿ID、slug、公開URLを更新します。新しい記事として作成すると、内部リンク台帳と検索評価が分散します。
リライト後はリンク元記事だけでなく、リンク先として使われているアンカーと説明が新しい本文に合うか確認します。必要な範囲だけ更新します。
公開前に確認したい実務ポイント
推測slugを使わない
タイトルからslugを予測して本文へ入れると、実際の公開URLとずれる可能性があります。
WordPressから返ったlinkとslugを正本へ戻します。
公開確認前の記事は候補から除外し、通常テキストで原稿を完成させます。
重複URLを検出する
複数の記事IDが同じURLを持つ、または一つの記事IDに複数URLがある状態は異常です。
台帳でURLとslugの重複を検査します。
統合・転送・誤登録のどれかを確定するまで自動挿入を止めます。
公開状態を毎回再取得する
以前公開済みでも、非公開化や削除、URL変更が行われることがあります。
本文生成時と公開前検査時に状態を取得します。
古い成功ログだけで利用可能と判定しません。
リンク先本文を確認する
HTTP 200だけでは、目的の記事が表示されているか分かりません。
投稿ID、タイトル、主要見出し、本文長を台帳と照合します。
ソフト404や誤転送を正常として扱いません。
末尾スラッシュを正規化する
表記違いで同じURLを別物として数えると、重複や未確認を誤検出します。
サイトの正規URL形式に合わせて比較用URLを正規化します。
本文にはWordPressが返した公開URLを使い、独自変換を最小限にします。
アンカーと内容を一致させる
リンク文言がリンク先の結論を過剰に約束すると、読者の期待を外します。
リンク先の記事タイトルと冒頭を確認し、本文に実際にある内容だけを案内します。
料金や制度の断定をアンカーへ追加しません。
設置数を目的にしない
内部リンクを一定数入れること自体が目的になると、関係の薄い記事を増やしがちです。
読者の次の疑問が明確な場所へ限定します。
品質ゲートでは件数に加え、リンク先記事IDと役割を確認します。
変更履歴を残す
URLやアンカーを変えても履歴がなければ、検索データの変化と結び付けにくくなります。
変更日、理由、旧値、新値、対象記事を記録します。
一度に多数を変えず、必要な改善だけに限定します。
個人情報を台帳へ入れない
内部リンク管理に本人氏名、家族氏名、自宅所在地は不要です。
記事ID、URL、公開状態、検索意図など業務情報だけを保存します。
共有範囲と権限を確認し、認証情報も保存しません。
公開後に再読する
リンクが技術的に動いても、文章の流れが不自然な場合があります。
スマートフォン表示でリンク前後を読み、文字被りや押しにくさも確認します。
HTML検査と人の読了体験を両方通して完了にします。
運用を安定させる追加手順
内部リンク候補の抽出条件
候補抽出では、記事マスターの状態が公開済みであること、公開URLとslugが空でないこと、WordPress投稿IDが取得できることを最初に確認します。その後、REST APIでstatusとlinkを再取得します。
管理表とWordPressが一致した記事だけを候補配列へ渡します。タイトルが似ているだけの記事、公開予定の記事、下書きURL、手入力した推測URLは除外し、除外理由を記事IDと一緒に残します。
検索意図のスコアリング
候補記事の主要キーワード、カテゴリー、読者の次の疑問、収益導線、既存アンカーを比較します。単語一致の数だけで選ばず、リンク元の段落で説明不足になっている内容を補えるかを見ます。
複数候補が同点なら、より直接的な実務手順を持つ記事、更新日が新しい記事、リンクが少ない記事など、自サイトの方針で優先規則を決めます。自動選択の理由を管理表へ残し、人が修正できるようにします。
本文への挿入位置
内部リンクは見出し直後へ機械的に置くのではなく、リンク先の内容を必要とする説明の末尾へ置きます。文章を読まずに一定文字数ごとへ挿入すると、同じリンクが連続したり、話題がずれたりします。
原稿生成時に各段落へ役割タグを持たせ、手順、具体例、関連設定、公開後確認のどれに当たるかで候補を選びます。挿入後は段落全体を読み、アンカーが自然な日本語になっているか確認します。
リンクHTMLの生成
hrefには公開URLをそのまま使い、内部リンクへ広告用のsponsoredを付けません。必要な属性はサイト方針に従い、相対URLと絶対URLを混在させる場合は正規化して比較します。
アンカーテキストはリンク先の内容が分かる言葉にし、同じページへ複数回リンクする必要があるかを確認します。HTML生成後にa要素を解析し、空URL、ドメイン違い、引用符崩れを止めます。
公開後の逆引き監査
内部リンク台帳から、あるリンク先記事を参照している全リンク元を抽出できるようにします。リンク先を非公開にする、slugを変更する、記事を統合する場合は、先に影響記事を一覧化します。
変更後はリンク元の本文を更新し、旧URLが残っていないか検索します。転送があるだけで完了にせず、アンカーと新しい本文の内容が一致すること、最終URLが正しいことを確認します。
同週4記事の扱い
同じ日に公開する4記事は、準備段階では相互に公開済みではありません。最初の本文には過去に公開確認済みの記事だけを使い、同週記事の相互リンクは4本すべての公開確認後に別工程で追加します。
この順番なら、一部記事が公開失敗しても先行記事に404リンクを残しません。追加時は既存投稿を更新し、新しいslugや重複投稿を作らないよう投稿IDを指定します。
GSCデータとの関係
内部リンク改善の判断にGSCのクリック、表示回数、CTR、平均順位を使う場合も、データがない記事を自動的に低品質としません。公開日と計測期間を確認し、十分な観察期間がある記事だけを比較します。
今回はGSCの日次同期が新規0件で、GA4は数値プロパティID未設定のエラーが残っています。計測済みと誤記録せず、リンク構造の品質とアクセス成果を分けて管理します。
台帳の更新責任
新規公開時は公開確認の完了後にURLと投稿IDを登録し、リライト時は同じ行を維持して更新日と確認結果を加えます。削除・統合では、状態を消さず履歴として残します。
自動処理が書いた行にも確認者と確認日時を入れます。成功ログだけで完成とせず、WordPress再取得とHTTP確認の証拠を残すことで、次回の原稿生成が安全な候補だけを使えます。
チェック項目を管理表へ落とし込む方法
1. 記事IDを全タブ共通キーとしてURLとslugを管理する
この項目では「記事IDを全タブ共通キーとしてURLとslugを管理する」を確認対象として独立させます。作業者の記憶や前回の成功表示に頼らず、対象記事ID、確認に使った原資料または公式ページ、確認日時を同じ行へ記録します。別の工程が合格していても、この項目の証拠がなければ完了へ進めません。
作業前には、管理表に保存された値と実サービスから取得した現在値を並べます。タイトルや表示文だけで同一と判断せず、ID、URL、日付、状態、対応する証拠を確認します。将来の予定や推測値は実績列へ入れず、確認できない内容は未確認として残します。
作業後には同じ取得経路でもう一度読み、更新した値が保存されているかを確かめます。書き込み処理の成功、画面の表示、公開後の取得結果を分けて記録すると、途中で失敗してもどの工程から再開すべきか判断できます。
差異が見つかった場合は、事実を変える大きな修正をせず、原因になった記事IDと項目だけを安全に直します。一時的な通信失敗は限定再試行し、認証、権限、事実関係を確定できない問題は公開を止めます。正常な他の記事や確認済みのデータはそのまま維持します。
2. status=publishとHTTP 200を確認した記事だけを候補にする
この項目では「status=publishとHTTP 200を確認した記事だけを候補にする」を確認対象として独立させます。作業者の記憶や前回の成功表示に頼らず、対象記事ID、確認に使った原資料または公式ページ、確認日時を同じ行へ記録します。別の工程が合格していても、この項目の証拠がなければ完了へ進めません。
作業前には、管理表に保存された値と実サービスから取得した現在値を並べます。タイトルや表示文だけで同一と判断せず、ID、URL、日付、状態、対応する証拠を確認します。将来の予定や推測値は実績列へ入れず、確認できない内容は未確認として残します。
作業後には同じ取得経路でもう一度読み、更新した値が保存されているかを確かめます。書き込み処理の成功、画面の表示、公開後の取得結果を分けて記録すると、途中で失敗してもどの工程から再開すべきか判断できます。
差異が見つかった場合は、事実を変える大きな修正をせず、原因になった記事IDと項目だけを安全に直します。一時的な通信失敗は限定再試行し、認証、権限、事実関係を確定できない問題は公開を止めます。正常な他の記事や確認済みのデータはそのまま維持します。
3. アンカーテキストとリンク先の検索意図を一致させる
この項目では「アンカーテキストとリンク先の検索意図を一致させる」を確認対象として独立させます。作業者の記憶や前回の成功表示に頼らず、対象記事ID、確認に使った原資料または公式ページ、確認日時を同じ行へ記録します。別の工程が合格していても、この項目の証拠がなければ完了へ進めません。
作業前には、管理表に保存された値と実サービスから取得した現在値を並べます。タイトルや表示文だけで同一と判断せず、ID、URL、日付、状態、対応する証拠を確認します。将来の予定や推測値は実績列へ入れず、確認できない内容は未確認として残します。
作業後には同じ取得経路でもう一度読み、更新した値が保存されているかを確かめます。書き込み処理の成功、画面の表示、公開後の取得結果を分けて記録すると、途中で失敗してもどの工程から再開すべきか判断できます。
差異が見つかった場合は、事実を変える大きな修正をせず、原因になった記事IDと項目だけを安全に直します。一時的な通信失敗は限定再試行し、認証、権限、事実関係を確定できない問題は公開を止めます。正常な他の記事や確認済みのデータはそのまま維持します。
4. 公開前URLや推測したslugを本文へ入れない
この項目では「公開前URLや推測したslugを本文へ入れない」を確認対象として独立させます。作業者の記憶や前回の成功表示に頼らず、対象記事ID、確認に使った原資料または公式ページ、確認日時を同じ行へ記録します。別の工程が合格していても、この項目の証拠がなければ完了へ進めません。
作業前には、管理表に保存された値と実サービスから取得した現在値を並べます。タイトルや表示文だけで同一と判断せず、ID、URL、日付、状態、対応する証拠を確認します。将来の予定や推測値は実績列へ入れず、確認できない内容は未確認として残します。
作業後には同じ取得経路でもう一度読み、更新した値が保存されているかを確かめます。書き込み処理の成功、画面の表示、公開後の取得結果を分けて記録すると、途中で失敗してもどの工程から再開すべきか判断できます。
差異が見つかった場合は、事実を変える大きな修正をせず、原因になった記事IDと項目だけを安全に直します。一時的な通信失敗は限定再試行し、認証、権限、事実関係を確定できない問題は公開を止めます。正常な他の記事や確認済みのデータはそのまま維持します。
5. 公開後に本文HTMLを再取得して内部リンクを検査する
この項目では「公開後に本文HTMLを再取得して内部リンクを検査する」を確認対象として独立させます。作業者の記憶や前回の成功表示に頼らず、対象記事ID、確認に使った原資料または公式ページ、確認日時を同じ行へ記録します。別の工程が合格していても、この項目の証拠がなければ完了へ進めません。
作業前には、管理表に保存された値と実サービスから取得した現在値を並べます。タイトルや表示文だけで同一と判断せず、ID、URL、日付、状態、対応する証拠を確認します。将来の予定や推測値は実績列へ入れず、確認できない内容は未確認として残します。
作業後には同じ取得経路でもう一度読み、更新した値が保存されているかを確かめます。書き込み処理の成功、画面の表示、公開後の取得結果を分けて記録すると、途中で失敗してもどの工程から再開すべきか判断できます。
差異が見つかった場合は、事実を変える大きな修正をせず、原因になった記事IDと項目だけを安全に直します。一時的な通信失敗は限定再試行し、認証、権限、事実関係を確定できない問題は公開を止めます。正常な他の記事や確認済みのデータはそのまま維持します。
6. URL変更や非公開化の影響記事を台帳から逆引きする
この項目では「URL変更や非公開化の影響記事を台帳から逆引きする」を確認対象として独立させます。作業者の記憶や前回の成功表示に頼らず、対象記事ID、確認に使った原資料または公式ページ、確認日時を同じ行へ記録します。別の工程が合格していても、この項目の証拠がなければ完了へ進めません。
作業前には、管理表に保存された値と実サービスから取得した現在値を並べます。タイトルや表示文だけで同一と判断せず、ID、URL、日付、状態、対応する証拠を確認します。将来の予定や推測値は実績列へ入れず、確認できない内容は未確認として残します。
作業後には同じ取得経路でもう一度読み、更新した値が保存されているかを確かめます。書き込み処理の成功、画面の表示、公開後の取得結果を分けて記録すると、途中で失敗してもどの工程から再開すべきか判断できます。
差異が見つかった場合は、事実を変える大きな修正をせず、原因になった記事IDと項目だけを安全に直します。一時的な通信失敗は限定再試行し、認証、権限、事実関係を確定できない問題は公開を止めます。正常な他の記事や確認済みのデータはそのまま維持します。
関連記事
管理表を使った品質設計はAIとApps Scriptで品質を落とさない運用、複数記事の失敗分離は4記事連続公開の設計、公開後確認はURLとstatusの再取得手順で解説しています。
WordPress運用の土台を確認する
内部リンク、画像、広告コードを正しく管理しても、公開先のWordPressが安定して動かなければ運用は続きません。運営者が利用しているエックスサーバーについて、現在のプランと仕様は申込み前に公式ページで確認してください。
確認した公式情報
画面や仕様は変更される可能性があるため、2026年10月10日に次の現行ページを確認しました。
まとめ
WordPress内部リンクをスプレッドシートで管理｜公開済みURLだけを使う方法で大切なのは、画面上の成功表示だけで処理を終えず、原資料または公式仕様、管理表、WordPressに保存された状態、公開後の実表示を同じ記事IDで照合することです。
未確認の数字や体験を足さず、失敗した工程だけを記事ID単位で直します。変更履歴と確認日を残しておけば、次回の更新やリライトでも同じ基準を再利用できます。
