Next SEO
Next.jsプロジェクトで構造化データを扱うMITライセンスのReactコンポーネント群
Next SEOは、Next.jsアプリの中でSchema.orgの構造化データ、すなわちJSON-LDを描画するMITライセンスのReactライブラリです。記事、よくある質問、商品、パンくず、組織など2ダースを超える型に型付きコンポーネントを用意しています。現在の系列は意図的に守備範囲を狭めました。READMEは通常のタイトルやメタタグにはNext.js自身のメタデータAPIを使うよう案内し、ライブラリ側はフレームワークが生成してくれないJSON-LDに集中しています。取り除いてくれるのは構造化データの定型作業であって、そのページが本当はどの型なのかという判断でも、渡した値が今も正しいかどうかでもありません。
いまのNext SEOとは何か
Next SEO(github.com/garmeeh/next-seo)は2018年から保守されているMITライセンスのTypeScriptライブラリで、Next.jsプロジェクトにJSON-LD構造化データ用の既製コンポーネントを提供します。コンポーネントを読み込み、型付きのpropsを渡すと、そのページが何であるかを検索エンジンに伝えるscriptタグが描画されます。著者と日付を持つ記事、価格と返品ポリシーを持つ商品、よくある質問の集まり、パンくずの経路、組織、動画、求人といった具合です。READMEはそれらを2ダース以上記載しており、加えてJsonLdScriptというプリミティブと、カバーされていないSchema.orgの型のための入力プロセッサ群も備えています。
このプロジェクトで興味深いのは、やめたことのほうです。Next SEOは、フレームワークがタイトルやメタタグについて何の方針も持っていなかった時代に、それらを管理する標準的な方法として生まれました。App Routerが一級のメタデータAPIを備えて以降、その仕事はフレームワーク自身が担うようになり、ライブラリは競合するのではなく、READMEで通常のメタタグには組み込み機能を使うようはっきり案内し、自らの守備範囲を構造化データに絞りました。旧Pages Router向けのコンポーネントは別のインポート先へ移されています。プラットフォームが仕事の一部を吸収したときに縮む依存関係は、膨らみ続ける依存関係より健全な兆候です。
構造化データが実際に効く場所
JSON-LDは、人間向けの文章の隣に置かれた、機械可読な主張のかたまりです。秘密のチャネルではありませんし、弱いページを強くもしません。変わるのは、人間と同じ読み方をせずにそのページが何であり再利用に値するかを判断しなければならないシステムにとって、どれだけ読み取りやすいかです。
- リッチリザルトの対象になる レビュー、よくある質問、商品、イベント、レシピなど、一部の型は検索結果の見え方を変え得ます。正しいマークアップはページを対象にするだけで、検索エンジンに表示を強いることは決してありません。
- 回答エンジンにとっての読み取りやすさ 著者、日付、エンティティ、質問と回答の対を明示すると、検索システムが曖昧さなく引用できる材料になります。これは生成エンジン最適化の機械的な半分です。
- 内部の一貫性 型付きコンポーネントを埋めると、誰がいつ書いたのかを明示せざるを得なくなります。手作りのサイトが静かに自己矛盾を起こすのは、まさにそこです。
小さなSaaSやストアにとって、役に立つ型は多くありません。サイト全体に組織かソフトウェアアプリケーションの型、コンテンツに記事とよくある質問の型、構造にパンくず、物販なら商品とレビューの型です。このライブラリは描画するすべてのscriptにnonceを渡せる点も特徴で、厳格なコンテンツセキュリティポリシーを敷いているなら効いてきます。自作すると半日溶ける類の細部です。概念そのものはスキーママークアップにまとめてあります。
これができないこと
構造化データは順位を動かすレバーではありません。妥当なマークアップはページを特定の表示形式の対象にするのであって順位を上げるものではない、というのがGoogleの一貫した説明であり、どれだけ入れても開く理由のないページを埋め合わせることはできません。理解されるページと、推測されるしかないページの差だと考えてください。
つまりこの種のライブラリは、育てる側ではなく作る側にはっきり属します。完璧にマークアップされたページにも、答える価値のある問いと、誰かがリンクする理由と、テーマを成すだけの兄弟ページが要ります。注釈の付け方ではなく何を出すかを選んでいる段階なら、その手前の判断が新しいサイトのSEOであり、open-seoは同じ仕事の調査側です。こちらは描画側になります。
スキーマを出荷することについての一次情報
AgentCeres — agentceres.comのAIグロースチーム — では、ライブラリを使わずApp RouterでJSON-LDを手書きしているので、これは選択の反対側からの比較になります。私たちの失敗は構文ではありませんでした。質問と回答のページは当初QAPage型を出力していて、一見それが自然に見えます。しかし誤りでした。この型は訪問者が競い合って回答を投稿するページを表すもので、私たちのページは私たち自身が書いています。FAQPageに変更しました。ページ自体は何も変わらず、変わったのはマークアップが主張していた内容の正しさだけです。そしてライブラリを使っていたなら、誤った型も正しい型と同じくらいきれいに描画していたはずです。
2つ目の教訓のほうが高くつきました。マークアップは主張の集まりであり、主張は静かに古びます。古びてもページ上では何も壊れて見えないからです。当サイトの/ask、/glossary、/growの各ページはバージョン管理下の型付きエントリで、内部リンク切れ、長すぎるメタタイトル、公開日の欠落があるとビルドが落ちるテスト群が付いています。おかげでスキーマに渡る値が誰にも気づかれずにずれることはありません。Next SEOが買えるのは正しい構文で、実際に時間も節約できます。正しい事実を買えるものは何もなく、どの事実を二度書かせないかを決めることだけがそれに当たります。この線引きこそ、当社のSEOコンテンツ担当が実際に守らせている内容の大半です。
FAQ
- App RouterでもNext SEOは必要ですか?
- 通常のタイトル、ディスクリプション、Open Graphタグには不要です。フレームワーク自身のメタデータAPIが担当しており、ライブラリのREADMEもそう明言しています。JSON-LDについては今も実利があります。型付きprops、妥当な既定値、nonceの指定は、必須項目の多い商品・レビュー・求人の型を入れ子のSchema.orgオブジェクトとして手で組み立てるより優れています。
- 構造化データは順位を上げますか?
- 直接には上げません。検索結果でより豊かな表示の対象になり、検索システムが解釈しやすくなるので、クリックや引用が増えることはありますが、頼れる順位要因ではありません。マークアップが完璧でも読む価値がなければページは見えないままなので、コンテンツ制作の最初ではなく最後に置く作業です。
- ライブラリを使わずJSON-LDを手書きしてもよいですか?
- 問題ありません。ページ型が数種類なら十分に妥当です。結局のところコンポーネントが描画するのはJSONオブジェクトを含むscriptタグ1つです。私たち自身がそうしています。引き換えになるのは保守で、手書きのスキーマはSchema.orgの変更からも自社データからもずれていきますが、型付きコンポーネントなら必須項目の欠落が静かな漏れではなくコンパイルエラーになります。
- 小さなSaaSやストアで重要なスキーマの型は?
- 多くのガイドが勧めるより少数です。サイト全体の組織型、売っているものに応じたソフトウェアアプリケーション型か商品型、実質のあるコンテンツへの記事型、本当に質問へ答えている箇所のよくある質問型、そしてパンくずです。ストアはこれに商品、レビュー、返品ポリシーの型を足すとよく、検索結果の見え方が目に見えて変わるのはその3つです。それ以外は、本当に必要とするページができるまで待って構いません。
You built it. Now grow it.
AgentCeres is a managed AI marketing team — specialists draft the SEO, social, and outreach that fill your links, you approve what ships. 14-day free trial, from $39/month.