アイランド、コンテンツコレクション、構造化データ、Web Vitals
Astroサイトが配信する内容をアイランドごとに確認する.
Astroサイトに対して、100点満点の総合スコアを1つ算出します。公開ページから取得した情報に基づき、8つの柱それぞれの判定根拠も提示します。調べるのは、ヘッダー、マークアップ、スキーマ、スクリプトの負荷です。余計な情報は見ません。つまり、アナリティクスの数値やログイン情報、フィールドデータなどは参照しません。この仕様は意図的なものです(検索クローラーも同じ情報しか見られないためです)。クローラーに見えないものは、診断にも映りません。
このページの内容 8つのセクション
AstroはSEOに強いのでしょうか?
はい。Astroなら検索エンジンに向いたサイトを作れます。Astroは、サイト上のすべてのUIコンポーネントをHTMLとCSSに変換し、デフォルトではクライアントサイドのJavaScriptを取り除きます。ホームページのソースを見てください。インスペクターではありません。生のレスポンスです。そこには、タイトル、メタディスクリプション、カノニカルリンク、そして1つのh1タグが入っているはずです。
クローラーは、レンダリングを待たずに見出し、本文、リンクを取得します。Astroが公開しているホームページのグラフによると、実際のAstroサイトの71%がCore Web Vitalsの基準を満たしています。ただし、これはベンダー側の数値です。「判断材料」として受け止めてください。「決定的な結論」とはしないほうが安全です。鵜呑みにする前に、ご自身のページを実際にテストしてみてください。
Astroはメタデータを自動生成しません。設定ファイルも、SEOにはまったく影響しません。タイトルやメタタグは、通常、共有レイアウト内のページヘッダーに追加します。そのため、スコアは作成したテンプレートと入力したコンテンツで決まります。この評価機能がページを分析し、足を引っ張っているピラーを示します。
アイランドは、クローラーやCore Web Vitalsにとってどのような意味を持つのでしょうか?
「アイランド」では、クローラーはページ上のすべてのコンポーネントをプレーンなHTMLとして読み取ります。訪問者のブラウザにJavaScriptが読み込まれるのは、「client:」ディレクティブを付けたコンポーネントだけです。コストがかかるのはそこだけです。ほかにはありません。
テンプレート内で「client:load」「client:idle」「client:visible」を検索してください。client:idle のコンポーネントは、ブラウザがアイドル状態になるまで待ちます。client:visible のコンポーネントは、ビューポートに入るまで表示を保留します。hero コンポーネントに client:load を設定すると、最初の読み込み時にスクリプトが読み込まれます。そのページに本当に必要でしょうか。多くの場合、必要ありません。
HTMLに何が含まれているかを確認してください。「view source」を表示すると、テキストやメイン画像が見えるはずです。web.devでは、最大の画像はJavaScriptを介さず、srcまたはsrcset属性を持つimg要素で読み込むよう推奨されているためです。Core Web Vitalsは、読み込み速度を測ります。インタラクティブ性と視覚的安定性も対象です。選択する設定は、それぞれ少なくとも1つの指標に影響します。この評価で計測するのは、ページが送信するスクリプトのサイズです。訪問者の実際の体験までは把握できません。Web.devによると、ラボ環境での測定は実環境での測定に代わるものではありません。実環境のデータもご確認ください。
レイアウトやコンテンツコレクションは、タイトル、カノニカル、スキーマをどのように制御するのでしょうか?
共有レイアウトが、これら3つすべてを制御します。タイトル、メタタグ、正規URL、JSON-LDをヘッダーに一度書けば、作成するすべてのページがそれを継承します。ミスも同じです。そのページだけでは済みません。サイト全体に広がってしまいます。
レイアウトを開き、次の3つを確認してください。プロパティとして渡すタイトルと説明です。サイト設定から生成されるカノニカルも見ます。さらに、JSON-LDスクリプトを確認します。canonical については、astro.config.mjs の site オプションでデプロイ先 URL を設定してください。base や trailingSlash も設定できます。site を省略すると、canonical を生成するための基準がなくなります。
コレクションは、ご自身で管理する残り半分を担います。Astroでは、Markdownコンテンツの整理、検証、型チェックの手段としてコレクションが挙げられています。ビルド前に、スキーマ内で説明文や日付の入力を必須にできます。Casperなどのテーマは、JSON-LDに加えてZodで検証されたコレクションを採用しているとしています。ご使用のテーマでも同様かどうか、確認してください。この評価が見るのは、出力されたHTMLの構造化データです。約束されたテンプレートは対象外です(約束はマークアップではありません)。
Astro vs Next.js:ブラウザへの送信量が少ないのはどちら?
各種比較記事を見ると、AstroはNext.jsよりもページに送るJavaScriptの量が少なくなっています。一方で Vercelによると、どちらのプラットフォームもサーバーサイドでレンダリングしたHTMLを提供するため、検索エンジンはどちらのページもインデックス登録できます。多くの人が真っ先に心配する点です。それでもNext.jsを選んでも、ページは引き続き検索結果に表示されます。
Tech Insiderが2026年9月に実施したドキュメントサイトのベンチマークでは、AstroのJavaScriptは約12 KB、Next.jsは約187 KBでした。Devsplainersの動画では、ホームページのJavaScriptサイズが1.75 KB対168 KBです。ご自身のホームページにも、同様の差がないか確認してみてください。Kunal Ganglani氏によると、一般的なマーケティングサイトでNext.jsのルーターとハイドレーションにかかるコストは80~150 KBです。ページサイズを比べるときの目安になる範囲です。数値は情報源やサイトによって異なります。あなたのサイトを測定したデータはありません。どの数値も鵜呑みにしないでください。ご自身のサイトでテストを行ってください。重要なのは、ビルド結果で得られる数値です。
Vercelは、HTTP ArchiveでAstroのCore Web Vitals合格率が高い理由について、フレームワークを使うサイトの傾向が結果に出ているだけで、ビルド自体の優劣を示すものではないと説明しています。だからこそ、数字は自分で見ます。ご自身の数値を確認するなら、LogRocketの手順を試し、「astro build」を実行して「npx serve dist」でdistディレクトリを配信するか、Next.jsを「output: 'export'」でビルドしてoutディレクトリを配信してください。本ツールの診断が読むのは、本番環境から配信されている実際のページです(一般論ではありません)。ベンチマークの傾向ではなく、ご自身のサイトの数字が見えます。ビルド出力と本番で配信されている内容を比べてみてください。その差が答えです。
Astroのサイトは、通常どこで点数を落とすのでしょうか?
Astroでスコアを落とす原因は、ほとんどがテンプレートやコンテンツの側にあります。まずそこです。そもそも、レンダリング自体で失点することは、まずありません。デフォルトの出力形式が、最初からHTMLだからです。フレームワークを疑うのは、ご自身が作成したページを確認した後にしてください。
まずはサイトマップです。@astrojs/sitemap の統合機能は、getStaticPaths() を含め、静的に生成されたルートからURLを拾います。SSRモードの動的ルートのエントリは、自動生成できません(ここは見落としやすい点です)。オンデマンドでレンダリングしているルートがあるなら、別の手段でサイトマップに追加できているか確かめてください。次に、多言語ページを開いてhreflangタグを見ます。canonicalタグが意図しないホストを向いていないか、末尾のスラッシュの形式がずれていないかも確認してください。
続いて画像です。マークアップを見れば、すぐにわかります。AstroのImageコンポーネントを使えば、累積レイアウトシフト(CLS)を防ぐ幅と高さが自動で入ります。ただ、素のimgタグには手動で書いた属性しか入りません。ここで差が出ます。構造化データ(JSON-LD)が不足している、インタラクティブにする必要のない要素にclient:loadを付けている、タイトルタグが重複している、といった点も減点対象です。診断レポートには判定理由が具体的に出ます。ですから、推測に頼る必要はありません。
外部からAstroのサイトをどのように確認すればよいでしょうか?
外部からAstroサイトを検証するなら、実際に配信されているレスポンスを直接見ます。そこで、まずHTMLを取得してください。ヘッダー、マークアップ、構造化データ、見出し構造、スクリプトや画像のリソース量、robotsやcanonicalの設定を確認します。トップページのURLに向けて curl を叩いてみましょう(ブラウザの表示とは別物です)。最初のHTMLレスポンスに、タイトル、canonical、h1、JSON-LDは含まれているでしょうか。そこになければ、クローラーにも見えていません。
続いて robots.txt とサイトマップの URL を開きます(地味ですが、これも大事です)。そして、個別記事、一覧、多言語ページなど、いくつかのテンプレートで同じ確認を繰り返してください。共通レイアウトを直しても、あるテンプレートでは直り、別のテンプレートには問題が残るケースはよくあります。
この無料診断ツールは、その確認作業をまとめて行います。手作業を減らせます。トップページと最大8ページのサンプルページを巡回し、8つの重要指標でサイトを調べて、約2分で100点満点のスコアを1つ算出します。職場のメールアドレスを入力すると、レポートへのリンクが1回限り送信されます(同一接続から実行できるのは1時間に3回までです)。ただし、本ツールは、サイトへのログイン、アナリティクスの読み取り、フィールドデータの取得は行いません。フィールドの数字は、ご自身の測定結果と見比べてください。
よくある質問.
01Astroにはサイトマッププラグインが必要でしょうか?
サイトマップを自動生成するなら、設定は必須です。省略できません。@astrojs/sitemap の統合機能は、getStaticPaths() で定義したルートを含む静的ルートからサイトマップを構築します。ただ、SSRモードの動的ルートには対応していません。まず astro.config.mjs 内の site オプションを設定してください。正規URL(canonical)とサイトマップの出力は、どちらもこの設定に依存しています。省略しても警告もビルドエラーも出ず、静かに両方とも正常に動かなくなります。
02AstroのアイランドはSEOに悪影響を及ぼしますか?
それだけでは不十分です。AstroはコンポーネントをHTMLとして出力し、JavaScriptを読み込む箇所を client: ディレクティブを付けた部分だけに絞ります。ここが効きます。アイランドはスクリプトの転送量と読み込み速度を直接左右します。ですから、スクロールせずに見える範囲(ファーストビュー)より下にある要素には、client:visible または client:idle の使用をご検討ください。この診断レポートが示すのは、実際に配信されたスクリプトの量です。訪問者の体感を推測するものではありません。
03サーバーレンダリングされたAstroサイトでも、診断で読み取れますか?
はい。本ツールは、検索クローラーと同じ方法で公開ページを取得します。事前ビルドの静的HTMLでも、オンデマンドでレンダリングされたHTMLでも、ヘッダー、マークアップ、構造化データをそのまま読み取ります。ただし、見る範囲は限られます。取得対象はトップページと最大8ページです。ログイン処理は行わないため、認証が必要なページにはアクセスできません。
04Core Web Vitalsの基準を満たすことは、Astro SEOのスコアが高いことと同じでしょうか?
いいえ。Core Web Vitalsが対象とするのは、読み込み速度、インタラクティブ性、視覚的安定性です。web.devでも説明されているとおり、ラボ測定は実環境測定の代わりにはなりません。ですから、ここは分けて考えます。本ツールのスコアには、パフォーマンスだけでなく、アーキテクチャ、セキュリティ、検索、スキーマ、AI対応状況、編集体験、運用状態も考慮されています。ただ、評価するのは公開済みのページそのものです。実環境データの代わりにはなりません。
出典
このページの事実は以下の資料に基づいています。確認日: 2026-10-25。診断そのものに関する数値は、その仕組みを説明するものです。
無料の自動診断