【ITニュース解説】How I Added Page-Level Deep Linking to a WordPress PDF Search Plugin
2026年09月16日に「Dev.to」が公開したITニュース「How I Added Page-Level Deep Linking to a WordPress PDF Search Plugin」について初心者にもわかりやすく解説しています。
ITニュース概要
WordPressのPDF検索プラグインを改善。検索結果がPDFの1ページ目ではなく、該当ページへ直接飛ぶようにした。PDFテキストをページ単位でDBに保存し、関連度の高いページを特定。ブラウザの機能で直接リンクを生成。ユーザーの手間を省く一方、データ量は増加する。
ITニュース解説
WordPressでPDFファイルを検索するプラグインにおいて、ユーザーが求めている情報がどのページにあるかを正確に伝え、直接そのページを開けるようにする機能「ページレベルディープリンク」を実装した話をする。従来のPDF検索システムでは、検索キーワードに合致するPDFファイルは見つけられるものの、常にPDFの最初のページが開いてしまい、ユーザーはそこから手動で該当箇所を探し出す手間があった。これは、検索としては機能しているものの、実用上は不便だった。
この問題を解決するためには、検索結果として単にファイル名だけでなく、どのページにキーワードが含まれているかという情報が必要になる。従来のシステムのデータベースは、wp_pdf_search_indexという一つのテーブルでPDFを管理していた。このテーブルには、PDFファイル全体のテキストを一つの長い文字列としてextracted_textというカラムに格納していた。そのため、どのPDFファイルにキーワードが含まれるかは分かっても、そのPDFの何ページ目にあるかまでは判別できなかった。すべてのページのテキストが結合されて保存されていたため、ページごとの区別が失われていたのだ。
そこで、まずデータベースの構造を根本的に変更した。ページごとの情報を保持するため、テーブルを二つに分割した。一つはwp_pdf_search_filesというテーブルで、PDFファイル自体の情報、例えばファイルID、WordPressの添付ファイルID、そしてPDFの総ページ数を管理する。もう一つはwp_pdf_search_pagesというテーブルで、各ページの具体的な情報、つまりどのファイルに属するかのファイルID、ページ番号、そしてそのページのテキスト内容を管理する。
この新しい構造に合わせて、PDFファイルをインデックス化(検索できるように情報を登録する)する処理も変更した。以前はPDF全体のテキストをまとめてデータベースに保存していたが、新しい方式では、PDFをページごとに解析し、各ページのテキストを個別の行としてwp_pdf_search_pagesテーブルに挿入するようになった。例えば、120ページのPDFであれば、wp_pdf_search_filesには1行が、wp_pdf_search_pagesには120行がそれぞれ追加される。これにより、各ページがどのファイルに属し、何ページ目であるかという情報が正確にデータベースに保存されるようになった。
次に、検索ロジックを改良した。ユーザーが特定のキーワードで検索した場合、そのキーワードが同じPDF内の複数のページにヒットする可能性がある。しかし、検索結果として表示されるのは通常、ファイルごとに一つであるため、そのPDFの中で最も関連性の高いページを特定する必要があった。このために、データベースのFULLTEXTインデックス機能とMATCH...AGAINST構文を利用し、各ページにおけるキーワードの「関連度(relevance)」スコアを算出した。そして、一つのPDFファイルに対して複数のページがヒットした場合、その中で最も関連度が高いと判断されたページを、ユーザーがアクセスすべき「ベストマッチページ」として選ぶロジックを実装した。これは、単にキーワードが見つかった最初のページではなく、キーワードが最も多く、または文脈上重要に現れるページを特定するための重要なステップだった。
最後に、特定されたページ番号を実際の機能するリンクに変換する方法だ。これは意外にも簡単で、ブラウザや一般的なPDFビューアが標準でサポートしている機能を利用する。具体的には、PDFファイル自体のURLの末尾に「#page=XX」という形式でページ番号(XXの部分)を追加する。例えば、PDFファイルのURLがexample.com/document.pdfで、5ページ目に直接リンクしたい場合、example.com/document.pdf#page=5とする。この「ハッシュ(#)の後にページ情報」という形式は、特別なプログラムを開発することなく、ウェブブラウザが自動的に指定されたPDFのページを開いてくれる。この機能のおかげで、私たちは関連性の高いページ番号を正確に特定することに集中できた。
この一連の改善により、ユーザーは検索結果から「120ページのマニュアルの答えのページ」に直接アクセスできるようになり、初めからファイルを開いて自分で情報を探す手間がなくなった。
しかし、この新しいシステムにはトレードオフが存在する。ページごとにデータを保存する方式は、以前のファイルごとに1行を保存する方式と比較して、データベースの行数とストレージ容量が大幅に増加する。また、PDFのインデックス作成時には、より多くのデータベースへの書き込み処理が発生するため、大きなPDFファイルの場合にはインデックス作成に時間がかかる可能性がある。例えば、300ページのPDFでは、300行分のデータが追加され、その分だけコストがかかる。このコストは、システムを設計する上で考慮すべき重要な点である。この機能がもたらすユーザー体験の向上と、それに伴うシステムリソースの消費を比較検討し、その価値があるかを判断する必要がある。