Rankbeamとは？
RankbeamはLaravel向けのオープンコアSEO基盤です。メタデータ、正規URL、ソーシャルカード、相互にリンクしたJSON-LD、サイトマップ、クローラー制御を提供する無料のMITコアと、任意で追加する商用Proの監視・ワークフロー機能で構成されます。 アプリに付け足す実行時のタグヘルパーではありません。自分のモデルと設定からSEOを解決し、同じ型付きデータをBlade、Inertiaのhead、JSON APIとして描画します。Proを使えば、デプロイ後も監視を続けます。
パッケージ構成
Rankbeamは、共通の対応バージョン表を持つ3つのパッケージで構成されます。
| パッケージ | ライセンス | 内容 |
|---|---|---|
rankbeam/laravel-seo | MIT、無料 | コア：メタデータの解決、相互にリンクしたJSON-LDスキーマグラフ、XMLサイトマップ、クローラー制御、無料のseo:audit、インポーター |
rankbeam/laravel-seo-filament | MIT、無料 | コアのseo_metaに書き込むFilament 4/5のフォームフィールドとライブプレビュー |
rankbeam/laravel-seo-pro | 商用 | 運用エンジン：0–100のスコア付きキュースキャン、リダイレクト管理、IPを保存しない404監視、リンク切れクローラー、Search Consoleインサイト、自分のキーを使うAI支援 |
この境界は意図的なものです。描画されたページが出力するものはすべてMITで、今後も無料です。料金の対象は本番環境の監査と監視の層です。商用Proは別パッケージであり、無料コアに含まれることはありません。
想定する利用者
Rankbeamが役立つのは、SEOを保存し、モデルに結び付け、複数ロケールで扱い、ヘッドレスで利用し、監査する場合です。動的なコンテンツやモデルに基づくコンテンツを持つ本番Laravelアプリが該当します。少数の静的ページにタイトルとディスクリプションを1つずつ付けるだけなら、小さな実行時メタヘルパーの方が適しています。後述の個別パッケージの組み合わせで十分な場合でも、その点を明記しています。
対応バージョン
全パッケージ共通の対応表です。
- PHP 8.2–8.4（Laravel 11）、8.2–8.5（Laravel 12）、8.3–8.5（Laravel 13）
- Laravel 11 / 12 / 13（Laravel 13にはPHP 8.3以降が必要）
- Filament 4 / 5（任意）
Rankbeamが置き換えないもの
RankbeamはLaravelアプリ自身のSEO出力を統合します。ホスト型の順位追跡サービス、キーワード調査ツール群、アクセス解析製品ではなく、順位、インデックス登録、AIによる引用を約束するものでもありません。XMLサイトマップの生成には独自実装ではなくspatie/laravel-sitemapを利用します。コンテンツ、ルーティング、アクセス解析は既存の仕組みを維持できます。
初めて使う場合は無料コアをインストールするか、このまま本番環境での実際の置き換え事例をご覧ください。Proと初期購入者向けオファーはrankbeam.devで案内しています。
3つのパッケージと連携コードでは足りない理由
多くのLaravelアプリが持つのは単一の「SEOパッケージ」ではなく、SEOスタックです。モデルごとにメタデータを保存するパッケージ、Filamentにフィールドを追加する別のパッケージ、ページをスキャンする3つ目のパッケージを組み合わせ、アプリ固有の連携層で整合させています。個々の部品には問題がありません。コストが生じるのはそれらの接続部分であり、その連携コードは自分で保守し続ける必要があります。
このページでは、そのような構成をRankbeamファミリーに置き換えた、実際の本番移行の結果を示します。以下の数値は宣伝用の推定ではなく実測です。
事例のアプリ
実際に本番稼働しているLaravelのコンテンツサイトです（ここでは匿名化しています）。
- 本番稼働約3か月の病院・組織向けコンテンツサイト。
- WordPressから移行し、サイトマップ上で約900ページ。
- 1日約20,000訪問。
- Laravel 12、Filament 4の管理画面、Bladeフロントエンド、MySQL。
置き換え前のSEOスタックは次のとおりでした。
| 層 | パッケージ |
|---|---|
メタデータ保存（モデルごとのseoテーブル） | ralphjsmit/laravel-seo |
| FilamentのSEOフィールド | ralphjsmit/laravel-filament-seo |
| ページスキャナー | backstage/laravel-seo-scanner |
| 各層をつなぐ処理全般 | 約30のアプリ独自クラス |
3つのパッケージを削除し、Rankbeamのコア + Pro + FilamentをインストールしてSEOテストスイートを実行したところ、SEOのリグレッションはゼロでアプリが起動しました。以下では、連携層に実際に必要だったものと、不要になったものを示します。
置き換えで削除できたもの
スキャナーの構成をRankbeamに置き換えることで、12の独自クラスを完全に削除できました。同等の処理をパッケージファミリーが担うため、アプリ側で維持する必要がなくなったものです。
| 削除したアプリのクラス | 役割 | 現在の提供元 |
|---|---|---|
Services/SeoService.php | アプリのSEOエントリーポイントのラッパー | コアリゾルバー + SEOファサード |
Services/SeoWarningEvaluator.php | タイトル・ディスクリプションの長さと画像寸法のしきい値 | コアのSEOWarningEvaluator（監査・プレビュー・スキャンで共用） |
Services/Seo/SeoAssetInspector.php | ローカル画像の寸法検査 | コアのLocalImageInspector |
Jobs/ScanAllPagesSeo.php | サイト全体のスキャンをキューへ投入 | Proのキュー型スキャンパイプライン |
Jobs/ScanPageSeo.php | ページ単位のスキャン | ProのPageScanner |
Jobs/ScanPublicPageSeo.php | 公開ページ単位のスキャン | Proのスキャンパイプライン |
Models/SeoScanBatch.php | スキャン実行の記録管理 | Proのseo_scan_runs |
Filament/Pages/SeoDashboard.php | SEO管理ダッシュボード | ProのSeoDashboardプラグイン |
Filament/Widgets/SeoScanProgressWidget.php | スキャン進捗ウィジェット | Proのスキャンウィジェット |
Filament/Widgets/SeoTrendChartWidget.php | スキャン推移ウィジェット | Proのスキャンウィジェット |
Facades/Seo.php | 保存パッケージを包むアプリのファサード | コアのSEOファサード |
Console/Commands/RecoverLegacySeoMetadata.php | 一度限りのメタデータ復旧 | コアのインポーター（seo:import-from） |
残したものも明記
移行時には、アプリ独自のリンク切れクローラー（約17クラス：スキャンジョブ、チェッカー、シード生成、ソース解決、2つのモデル、2つの列挙型、2つのイベント、Filamentリソースと3つのウィジェット、2つのコマンド）と、メタデータ・スキーマ用のヘルパー（CustomSEO、EntitySeoSection、DynamicSeoDataResolver、SitewideSchema、SeoKeywords）を意図的に残しました。合わせてさらに約22クラスです。初日に削除しなかったのは、Rankbeam側の代替機能がその後に追加されたためです。独自クローラーにはProのリンク切れクローラー、CustomSEO/EntitySeoSectionにはFilamentの関連モデルの対象指定とSERP・ソーシャルプレビュー、SitewideSchemaにはコアのスキーマグラフが対応します。ファミリー全体を採用すれば、合計およそ36クラスに及ぶ独自処理をパッケージ側に移せます。
個々のパッケージが悪いという話ではありません。問題は統合部分です。メタデータの変更をスキャナー、ダッシュボード、描画されたheadへ反映する十数以上の連携クラスは独自コードであり、上流の保守元も、自分たち以外のテストも、他の利用者からのバグ報告もありません。
機能の比較
| 機能 | 個別構成（3パッケージ + 連携コード） | Rankbeamファミリー |
|---|---|---|
| モデルごとのメタデータ保存 | メタデータ用パッケージ | コア（seo_meta、MIT） |
| ロケール対応の保存 | 通常は連携層で対応 | コア：seo_metaのカラムでロケールを区分 |
| FilamentのSEOフィールド | Filament-SEOパッケージ | laravel-seo-filament（MIT） |
| 関連モデルのSEO編集 | フィールドコンポーネントを自分でラップ | 標準のtarget:リゾルバー |
| SERP + ソーシャルのライブプレビュー | Blade/Alpineで独自実装 | 編集用のタブ付きプレビューを内蔵 |
| ヘッドレス描画（Inertia / Livewire / JSON） | 事例のアプリはBladeを使用。他の構成には連携が必要 | 1つのリゾルバー → Blade、Inertia、Livewire、JSON（共通仕様に対してテスト済み） |
| ページスキャナー + 優先順位付きの問題 | スキャナーパッケージ | Proのスキャンパイプライン + IssueRegistry |
| 0–100のスコア | 連携コードで実装、またはなし | Proの明示的でバージョン管理された基準 |
| リダイレクト + 404からの復旧 | 別パッケージまたは独自実装 | Proのリダイレクト管理 + IPを保存しない404監視 |
| リンク切れクローラー | 独自実装（事例のアプリでも自作） | Proの上限付き・再開可能なクローラー |
| JSON-LDスキーマグラフ | ビルダー + 独自の@id連携 | コアの相互リンクしたOrganization/WebSite/WebPageグラフ |
| XMLサイトマップ | サイトマップ用パッケージ | コアのサイトマップレジストリ（spatie/laravel-sitemapを利用） |
| WordPress / Yoast / Rank Mathのインポート | 一度限りのスクリプト | コアのseo:import-from + 実行手順書 |
| 接続部分の保守担当 | 自分たち | 同じリリース系列のパッケージファミリー |
連携コードでは対応しにくい3つの点
1 — 一体として開発されるファミリーとリリース系列。 個別の3パッケージには、3組の保守者、変更履歴、更新周期があります。そのずれを吸収するのが連携コードです。Rankbeamのコア、Pro、Filamentは、共通の対応表と文書化された更新時の境界に沿ってバージョン管理されます。挙動の変更は一か所で告知され、2つのパッケージの不一致によって初めて発見する必要はありません。
2 — 慣習ではなくカラムとしてのロケール対応。 seo_metaは保存層でポリモーフィックかつロケール別に区分されています。複数ロケールのSEOは(model, locale)ごとの行であり、シリアライズした塊や後付けの連携テーブルではありません。リゾルバーの優先順位は現在のロケールを標準で読み取ります。
3 — 1つのリゾルバーによるヘッドレス描画。 Rankbeamは型付きのSEODataを解決し、同じデータをHTML、InertiaのHeadペイロード、JSON配列として描画します。Blade、Inertia（Vue/React/Svelte）、Livewireについて共通の出力仕様に照らして検証しています。管理画面は不要で、Proのすべての機能もartisanからヘッドレスで実行できます。
無料コアに含まれないもの
Rankbeamはオープンコアであり、その境界は意図的です。composer requireを実行する前に、何が含まれるか把握できます。
| パッケージ | ライセンス | 含まれるもの |
|---|---|---|
rankbeam/laravel-seo | MIT、無料 | メタデータの解決、JSON-LDスキーマグラフ、サイトマップ、無料のseo:audit、インポーター |
rankbeam/laravel-seo-filament | MIT、無料 | seo_metaに書き込むFilamentフォームのフィールドとセクション |
rankbeam/laravel-seo-pro | 商用 | キュースキャン + 優先順位付きの問題 + 0–100のスコア、リダイレクト、404監視、リンク切れクローラー、Search Console、AI支援、Filamentダッシュボード |
有料となるのは、テクニカルSEO監査とサイト監視の機能群です。スキャン、スコア、リダイレクト、404からの復旧、クローラーが該当します。メタデータエンジン、スキーマグラフ、サイトマップ、同一プロセス内の無料監査はMITで、無料のままです。
確認できる特徴は2つあります。
- 実行時のライセンス確認なし。 Proはインストール時にプロジェクト単位でライセンスを付与します。ライセンス確認のための外部通信はなく、停止スイッチでアプリが落ちることもありません。Proは自分のログ向けにローカルの運用テレメトリを出力しますが、オプトアウトでき、当方に送ることはありません。
- 自分のキーを使うAI。 任意のAI支援は、利用者自身のAnthropic、OpenAI、Google、またはローカルモデルのキーを使います。Rankbeamが中継、従量課金、再販売することはなく、デフォルトは無効です。
個別パッケージの組み合わせで十分な場合
少数の静的ページに<title>とディスクリプションを1つずつ付けるだけなら、実行時のタグビルダーで十分です。Rankbeamが役立つのは、SEOを保存し、複数ロケールで扱い、モデルに結び付け、ヘッドレスで利用し、監査する場合です。パッケージ間の連携が実際に保守すべきコードになる段階が目安です。
リスクを抑えたWordPressからの移行
事例のアプリは約900ページのWordPress移行でした。長年積み重ねたYoast/Rank Mathの最適化を失うリスクが大きい利用者です。Rankbeamでは、その移行を安全な手順として扱います。
- 併用する。 稼働中のサイトと並行してRankbeamを用意します。この段階では何も削除しません。
- インポートする（先にdry-run）。
seo:import-from yoast/rank-math/wordpress-csvでタイトル、ディスクリプション、正規URL、robots、フォーカスキーワード、ソーシャル用の上書き値を読み取ります。インポーターは冪等で、デフォルトでは空欄だけを補完します。--overwriteを指定しなければ設定済みのメタデータを保持し、--dry-runでは何も書き込みません。 - リダイレクトを引き継ぐ。 コアがバージョン付きのリダイレクトCSVを出力します。Proの
seo-pro:redirects-importは書き込み前に全行を検証し、ループ、安全でない宛先、重複を拒否します。 - 削除の前に検証する。
seo:audit --strictは、問題が1つでもあれば非ゼロで終了するCI・切り替え判定用のゲートです。従来のWordPressデータベースは、自分で削除を選ぶまで変更されません。
全手順はWordPress移行の実行手順書、フィールドごとの対応とトークン処理はWordPressからの移行を参照してください。LaravelのSEOパッケージ（ralphjsmit、artesaos、Spatie）から切り替える場合は、パッケージ移行ガイドを参照してください。
規模が大きくても対応できるか
事例アプリの厳しい条件である、1日約20k件のリクエストすべてでのリゾルバー実行と、約900ページのリンククロールには、それぞれテストスイート内のベンチマークがあります。検証するのは手動調整した実時間ではなく、クエリ数とジョブの上限という決定的な改善です。
リゾルバーのキャッシュ：保存済みキャッシュにヒットすればDBアクセスはゼロ。 任意の解決結果キャッシュを有効にすると、キャッシュヒット時は優先順位の連鎖全体を省略します。ベンチマークでは同じモデルを25回解決します。
| DBクエリ数 | |
|---|---|
キャッシュなし（毎回seo_metaを再読込） | ≥ 25 |
| 保存済みキャッシュにヒット | 0 |
キャッシュはデフォルトで無効で、大規模運用向けの選択肢として文書化しています。seo_meta、コンテンツフィールド、デフォルト値を変更すると、対応するエントリが無効になります。設定 → キャッシュを参照してください。
リンク切れクローラー：900ページでもジョブごとに上限を維持。 クローラーのベンチマークでは、生成した約900ページのコーパスを実際のジョブで処理します。
- 18以上の上限付きジョブで完了（1ジョブ50ページまで）。
- どのジョブも50ページの上限を超えて巡回しません。
- 1,800リンクを確認し、到達不能な宛先をすべて、リンク切れ確認済みの永続的な検出結果として記録します。
実行ごとの有限の上限と、ジョブごとの厳格な時間枠を設けています。シードの取得時とすべてのリダイレクトの各段階でSSRF検証を行い、DBリースによりスコープごとに有効な実行を1つに制限します。運用方法は本番環境の設定ガイドを参照してください。
実行環境でのテスト
3つに分かれた対応表ではなく、全ファミリーで1つの対応表を使います。
- PHP 8.2–8.4（Laravel 11）、8.2–8.5（Laravel 12）、8.3–8.5（Laravel 13）
- Laravel 11 / 12 / 13
- Filament 4 / 5
3つのパッケージを連携させ続けるべきか
個別の構成を統合するために十数以上の独自クラス、自分では制御できないリリース周期、構成固有の描画連携、手作業で追加するロケール処理が必要になる一方、一体として開発されたヘッドレス・ロケール対応のファミリーで連携コードを削除でき、実際の900ページ・1日20k件の本番アプリで実績があるなら、個別構成を安全なデフォルトと考え続ける理由は薄れます。
クイックスタートから始めてください。composer requireから完全な<head>の描画まで5分で進められます。