ACQUA JOURNAL
リンクを新しいタブで開くべき?WordPressの指定・案内・戻る操作を点検する

外部リンクは全て新しいタブにすればよい、同じタブなら読者が戻れない、とは限りません。リンク先で何を行い、元のページへどう戻るかを考え、指定と実際の操作を揃えます。
本記事は、記事のリンクを更新する企業と、共通部品を実装する制作会社向けです。内部リンクの棚卸しとは分け、タブの指定・事前案内・端末での動作を検収します。
1. 読者がリンク先で何をするかを決める
サービスの詳細へ進む、本文を参照しながら資料を見る、申込みのため外部サービスへ移る、といった目的を整理します。外部サイトかどうかだけで動作を固定せず、読者の仕事へ合わせます。
元の画面を残す必要と、迷いの負担を比べる
入力中の画面を残して規約を読む場合、新しいタブが役立つことがあります。一方、短い記事内の関連説明を次々開くと、タブが増えて現在地を見失う場合があります。勝手に閲覧時間を長く見せることを判断基準にしません。
通常のリンクでは、利用者が自分で別タブを選ぶ操作もあります。標準のブラウザー操作を妨げる独自スクリプトを加える前に、必要な動作を確認してください。

2. リンク文字、行き先、開き方を揃える
リンクだけを見ても行き先が分かる文言にし、URLの対象ページと本文を確認します。「詳しくはこちら」が多数ある場合は、サービス、資料、制度など参照する内容を伝える文言を検討します。
新しいタブで開く動作を使う場合、必要に応じて事前に案内します。W3Cの新しいウィンドウを開く前の案内は、この動作を利用者が理解できるようにする参考です。全リンクを別タブへする推奨ではありません。
| 目的 | 点検すること |
|---|---|
| 次の説明へ進む | 行き先と通常の戻る操作 |
| 元の画面を参照する | 新しいタブの案内と戻る方法 |
| 外部サービスへ移る | 対象サービスと次の操作 |
| 資料を読む | 形式、開き方、元ページへの戻り方 |
アイコンだけで開き方を示す場合も、意味が伝わるかを確認します。文字での補足や読み上げ時の案内が必要か、共通部品の設計と揃えます。

3. HTMLのhref、target、relを確認する
リンク先はhref、開く閲覧先の指定はtargetなどで扱います。通常のリンクか、JavaScriptが開くリンクかを区別し、保存された投稿と公開HTMLを照合してください。
noopenerとnoreferrerは、別の役割を持つ
MDNのリンク要素の説明では、targetとrelの指定を確認できます。noopenerは開いた先から元ウィンドウを操作する経路に関わり、noreferrerは参照元情報の送信にも関わります。名前が似ているから両方が必須と一律に扱いません。
現在の多くのブラウザーではtarget="_blank"にnoopener相当の扱いがあります。対象環境と設計を確認し、明示する場合も公開HTMLで読み戻します。参照元や解析に関わる変更は、リンク表示の修正へ無断で混ぜないでください。

4. 投稿のリンクと、共通部品の指定を分ける
WordPressの投稿内リンクは、使用するブロックや編集方式で新しいタブの設定位置が異なります。対象リンクを選び、設定を読み、保存後の本文と公開ページを確認します。
一方、ヘッダー、共通ボタン、関連記事、外部サービスのリンクはテーマや追加機能が生成している場合があります。投稿の設定を変えても共通リンクが変わるとは限りません。どこが管理元かを担当者へ確認してください。
同じ部品が複数ページにある場合は、使用先を調べます。全てのa要素へスクリプトで新しいタブを強制する修正は、電話、メール、ページ内の目次、フォーム等まで影響し得るため、必要性と範囲を先に確かめます。

5. PC、スマホ、キーボードで実際に開く
公開ページからリンクを選び、正しいURL、タブ数、元のページの状態を見ます。開いた先だけでなく、元へ戻った後も本文や入力状態を扱えるか確認してください。
スマホでは、アプリ内表示も区別する
端末やアプリ内ブラウザーによって、別画面・タブ・アプリへの移動は異なる場合があります。HTMLで新しいタブを指定しても、全環境で同じ画面になる保証ではありません。確認した端末と経路を記録します。
キーボードでリンクへ移動し、選んで、元へ戻る操作を試します。自動検査でtargetが存在したことだけを、利用者が迷わない動作の検収にしないでください。

6. PDF、電話、メール、ページ内移動を別に試す
PDFは表示される場合と保存する場合があり、通常のWebページと動作が異なります。資料形式を伝え、読んだ後に元へ戻れるかを確認します。保存完了をリンククリックだけで報告しません。
電話やメールは対応するアプリへ渡すリンクです。telとmailtoの点検へ分け、Webページ用のタブ指定を無条件に追加しないようにします。
同じページの見出しへ移る目次は、そのページ内で位置を変えるのが通常の目的です。別タブへ強制していないか確認し、移動先や固定ヘッダーの問題は目次リンクの確認へ分けます。

7. 自動点検と、代表経路の実操作を組み合わせる
リンク一覧にURL、文言、管理元、target、rel、案内の有無を記録します。全リンクの属性を集計すれば、意図と違う共通設定を見つける材料になります。
応答コードが正しくても、目的は達成しない場合がある
リンク先が開くこと、読者が正しい資料や受付へ進めること、戻る操作ができることは別です。移転先のトップページへ飛ぶリンクや、終了した申込みを案内するリンクは、HTTPが成功しても内容の見直しが必要です。
確認結果には、対象、期待した動作、実際の動作、変更範囲、原本、戻し方を残します。共通リンクを直した場合は使用先も検収し、日次で目的なく全リンクを開き直す運用にしません。

8. リンク修正の範囲と、完成条件を相談する
自社では、対象URL、リンク文言、現在の行き先、望む開き方、元へ戻る必要を整理できます。企業向けWeb支援へ記事の更新・保守を、制作会社向け実装支援へ共通部品・属性・スクリプトの調査と改修を分けて相談します。
相談窓口には、困る操作と変更できる範囲を伝えてください。フォーム送信、外部契約、解析設定の変更は、リンクの表示改善と分けて確認します。
解決状態は、読者が行き先と開き方を理解し、必要な情報を読んで元の作業へ戻れ、更新担当が指定と管理元を把握できることです。タブを増やすことを成果にはしません。
一次資料の確認日:2026年10月8日。
