WordPress 4.6のinline link checkerはURLの入力間違いを見つけてもlink先の確認を代わりにしない

記事へlinkを入れるとき、URLの文字列が正しい形でも、link先が読者にとって適切とは限りません。WordPress 4.6のinline link checkerは、editorでlinkを作るときの入力間違いを見つける助けになります。しかし、link先が公開されているか、説明と同じ内容か、外部siteの条件が変わっていないかまでは代わりに判断しません。

4.6では、editorがURLを確認し、誤ったlinkを作りにくくします。たとえばhttps://wordpress.org/example.orgのようにdomainを重ねて書いた場合を確認できます。これは記事を書いている途中の入力補助です。公開後も使えるlinkを選ぶ判断とは、別に扱います。

linkは記事の文の続きです。「申込みはこちら」と書いて別のpageへ送るなら、そのpageで申込みができなければなりません。「公式資料」として紹介するなら、発行元と内容を読者が確かめられる必要があります。URLが404にならないことだけでなく、本文で約束した情報へ着くかを確認します。

URLの形とlink先の内容を分ける

linkの確認には少なくとも二つの段階があります。

説明用の仮例として、記事から申込pageへlinkを置く場合を考えます。editorでURLの誤記がないと分かっても、申込を一時停止しているpageへ向けていれば読者は進めません。URL、公開状態、案内内容、必要なら別tabで開く設定を分けて確認します。

申込pageへ向けるlinkでは、読者が最初に知るべき条件も確認します。受付時間、対象地域、料金、必要な入力項目が、本文の案内と食い違っていないかを見ます。記事で「無料相談」と書いて、link先では対象条件があるなら、その条件を隠しません。linkを増やすことと、読者が迷わず次の操作へ進めることは別です。

内部linkでは、公開前の下書きやprivateのpageへ向けていないかを確認します。編集画面で開けるURLでも、一般の読者が開けるとは限りません。記事の旧URLを新しいURLへ変えた場合も、過去の投稿から古いURLへlinkが残ることがあります。URLを文字列で見るだけでなく、ログアウトしたbrowserで開き、読者と同じ画面で確認します。

外部linkでは、移動先が自分のsiteではないことを読者へ分かるようにします。資料を引用するために外部siteへ送るのか、問い合わせや購入のために外部serviceへ送るのかで、本文に書く理由が違います。別tabで開くなら、その必要があるlinkだけにし、戻れることを利用者が理解できるようにします。外部siteの運用や表示は自分では直せないため、確認した日も残します。

link文字も確認します。「こちら」だけでは、どこへ行くかが周囲の文を読まなければ分かりません。資料名、申込先、問い合わせpageのように、link先の役割が読める文にします。長いURLを本文へそのまま出す必要はありませんが、何を開くlinkかを隠しません。URLの入力間違いを防いでも、link文が曖昧なら読者は判断できません。

公開前は読者の操作として一度開く

inline link checkerを使っていても、公開前に重要なlinkを実際に開きます。すべてのlinkを同じ優先度で確認できない場合は、問い合わせ、申込、料金、資料の根拠、主要な関連記事の順に選びます。読者の次の行動や記事の根拠に関わるlinkは、一覧の末尾でまとめて確認しません。

1. 記事内のinternal linkとexternal linkを分ける。
2. 読者が最初に必要とするlinkから実際に開く。
3. link先のtitle、公開状態、案内内容が本文と合うか確認する。
4. 外部siteへ移る理由が本文に書かれているか確認する。
5. 編集日とlink先を記録し、内容が変わった場合に見直せるようにする。

説明用の仮例として、記事の途中に三つのlinkがある場合を考えます。一つはsite内の関連記事、一つは問い合わせform、一つは外部の公式資料です。関連記事はtitleと公開状態、問い合わせformは入力から通知まで、外部資料は発行元と記載内容を確認します。三つともURLを開く作業ですが、確かめる内容は同じではありません。

referenceとして外部資料へlinkするなら、資料の発行元と日付も見ます。URLだけが残っていても、別の内容へ差し替えられていれば根拠になりません。記事で扱う制度、仕様、料金のように変わり得る情報なら、資料の公開日と記事の日付を照らします。editorの入力補助と、出典を選ぶ作業を混同しません。

linkを開いたときに別のURLへ移る場合も確認します。httpからhttpsへ移ること、旧pageから新pageへ移ること自体は問題ではありません。問題なのは、意図しないtop pageへ飛ぶ、別の商品pageへ飛ぶ、ログイン画面で止まるような場合です。本文で示した内容へ到達できるかを見て、redirectがあることだけで良しとしません。

公開後に変わりやすい外部linkは、最終確認日と担当を残します。更新のたびに全記事を読み直せなくても、どの資料が重要か、どの記事に外部serviceへの導線があるかが分かれば、見直す順を決められます。link checkerで見つける入力上の問題と、運用の中で変わる問題を同じ検査へ期待しません。

記事編集とlinkの責任を分ける

制作側がthemeやeditorの設定を整えることはできます。しかし、どのpageへ読者を送るか、停止中の案内を外すか、外部資料を根拠に使うかは、記事とsiteを運用する側が判断します。入力間違いを減らす仕組みと、link先を承認する責任は別です。editorの警告が出ないことを、記事の確認が終わった印にしません。

制作側へ頼むときは、内部linkの表示方法、外部linkを別tabで開く条件、link切れを確認する範囲を渡します。制作側はthemeやeditorで意図した属性が出るかを確認します。記事の担当者は、link先の内容、本文との関係、更新後の見直しを確認します。どちらかが行う確認を曖昧にすると、公開画面ではlinkが動いていても、案内として役に立たないことがあります。

最初の一手は、公開予定の記事から重要なlinkを三つ選び、link文、本文で説明したこと、link先で確認できること、最終確認日を並べることです。internal link、問い合わせform、外部資料を一つずつ選ぶと、確認する種類を分けられます。四つがそろってから公開します。inline link checkerはURLを打ち間違えないための助けであり、読者を正しい情報へ導く最終確認の代わりにはなりません。