Astroブログは記事が増えると何が変わるか―分類・検索・保守とアクセス解析の実例
記事数が増えたAstroブログで、分類、ページネーション、検索、内部リンク、リンク切れ確認など何が必要になったかを、ゆまラボの実例とアクセス解析から増えていく機能を分けて確認します。
ブログを作り始めた頃は、記事を追加できれば十分に回った。
新しいMarkdownを1つ作る。記事一覧の先頭に出る。必要ならタグを付ける。
記事が数件なら、この形でも困らない。
ゆまラボも最初は同じ。記事が増えるにつれて、「記事を書くこと」とは別の作業が増えてきた。
カテゴリを分ける。連載を分ける。タグの表記を統一する。記事一覧をページ分けする。検索を付ける。パンくずを追加する。リンク切れを確認する。
さらにアクセス解析を始めると、今度は「どの記事が読まれているか」をサイト側へ戻したくなる。トップページの「注目コンテンツ」もその一つになる。
記事が増えたことで必要になるものと、データが見えるようになったことで追加したくなるものは少し違う。
今回は、その2つを分けて考える。
記事が増えてもAstro自体がすぐ限界になるわけではない#
最初に切り分けたいのは、記事数が増えることとAstroの処理能力は同じ話ではないこと。
AstroのContent Collectionsは、ブログのように同じ構造を持つコンテンツを管理するための仕組みとして用意されている。
公式ドキュメントでも、Content Collectionsはコンテンツの整理、検索、型チェック、Frontmatterの検証に使え、build-time collectionは数万件規模のコンテンツにも利用できるとしている。ページ数が非常に多い場合は、すべてをビルド時に生成せず、必要になったときにルートを生成する方法も選べる。
ゆまラボで記事が数十件になった段階で問題になっているのは、Astroが記事を処理できないことではない。
問題になったのは、人が記事を探す方法と、運営側が増えた情報を維持する方法。
確認時点の記事一覧では、33件の記事に対してページネーションが表示されている。
33件なら全件を1ページへ並べても技術的には表示できる。
ただ、読み手が毎回一覧を下まで探す必要はない。記事が増えた時点で、表示できるかより「目的の記事へ移動できるか」の方が気になるようになる。
一覧だけでは足りなくなり、分類と検索が必要になった#
ゆまラボでは記事数がまだ一桁の段階から、後で増えることを考えてFrontmatterへ分類情報を追加した。
第9回 Astroブログの記事へカテゴリと連載情報を追加する―第1回から第8回のMarkdownを整理では、記事の内容を分類するcategoryとsubcategory、続き物を管理するseriesとseriesOrderを分けた。
その後、第10回 Astroブログにカテゴリ・連載・タグの導線を追加する―Frontmatterから記事一覧を自動生成で、それらを実際のナビゲーションへ使うようにした。
役割は今も分かれている。
category / subcategory
→ 記事の内容
series / seriesOrder
→ 続き物の順番
tags
→ Astro、Cloudflare、SEOなど横断的なキーワード記事が少ないうちは、この違いを意識しなくても記事一覧から探せる。
増えてくると、例えば「Astroの記事を読みたい」と「Astro＋Cloudflareの連載を第1回から読みたい」は別の要求になる。
さらに記事が増れた段階では、ヘッダーへカテゴリ・連載・タグへの導線を追加し、サイト内検索も追加した。
Googleも内部リンクについて、重要なページへサイト内の別ページからリンクし、分かりやすいアンカーテキストを使うことを勧めている。一方で「内部リンクは何本必要」という決まった数はない。
記事が増えたから、すべての記事から大量の関連記事へリンクすればよいわけではない。
本文で直接関係する記事へリンクする。カテゴリ・タグ・検索から別の入口も用意する。読者が迷う箇所を見て導線を足す。
この方が運用しやすい。
記事より速く増えるのが分類ページと保守対象#
記事が30件なら、サイト全体も30ページ程度に見える。
実際はそうならない。
Astroで記事からカテゴリ、サブカテゴリ、タグ、連載、ページネーションなどを生成すると、1記事に対して複数の一覧ページが関係する。
ゆまラボでは2026年9月11日に外部のリンク切れチェッカーで確認し、以下の結果になった。
Processed 360 web pages, found 0 broken links記事数より、確認対象になったWebページ数の方がかなり多い。
リンク切れチェッカーでゆまラボ360ページを確認―検出0件と無料版で見えない範囲でも、この時点のbroken linkは0件と確認している。
記事が増えると、本文だけでなく周辺ページも保守対象になる。
例えばタグは、記事を追加するたびに新しい表記が入りやすい。
ゆまラボでは一度直したタグ重複が新規記事の追加後に再発したため、タグマスタとaliasを使う方式へ変更した。
Cloudflare Workers
cloudflare workersのような表記違いを記事ごとに直すだけでは、次の記事で再発する可能性がある。
そこで「問題が出た記事を毎回直す」より、「追加時に同じ問題が入りにくい仕組みにする」方向へ変えた。
記事数が増えたときに必要になるのは、ページを追加する機能だけではない。
Frontmatterの検証
カテゴリ・タグの正規化
ページネーション
サイト内検索
sitemap
パンくず
内部リンク
リンク切れ確認
ビルド時の検証のように、増えたコンテンツを壊さず維持する処理も増える。
Googleのサイトマップの説明でも、サイト内リンクが適切なら多くのページは通常のクロールで見つけられる一方、サイトが大きくなったり構造が複雑になったりすると、サイトマップが発見を補助できるとしている。
アクセス解析を始めると「必要」以外の機能も増える#
ここからは少し種類が違う。
カテゴリや検索は、記事が増えて探しにくくなったため追加した。
アクセス解析から出てくるのは、「なくても記事は読めるが、データを見ると欲しくなる機能」が多い。
ゆまラボではCloudflare Web Analyticsでページビュー、Path、Referer、Device typeなどを確認し、その後Google Analyticsも追加した。
実際のCloudflare Web Analyticsでは、URLごとの状況やCore Web Vitalsを確認できている。
アクセス解析を見るようになると、次の疑問が出てくる。
どの記事が最近読まれているか
検索とSNSのどちらから来ているか
古い記事がまだ読まれているか
公開した新記事へ読者が移動しているか
よく読まれる記事から次に何を案内するかここから「注目コンテンツ」や関連記事を追加したくなる。
ゆまラボでは第3回 人気記事を自動表示したい―Cloudflareでも見られるがGoogle Analyticsを使うことにするで、トップページへ直近30日の人気記事を3～5件出す案を考えた。
条件は、
対象期間
直近30日
対象
通常の記事ページ
表示件数
3～5件
並び順
ページビューの多い順としている。
Google Analytics Data APIの公式ドキュメントでも、直近期間の上位ページとページビューを取得する例が挙げられている。Data APIを使えば、管理画面を見て毎回手で記事を選ばなくても、レポートデータをプログラムから取得できる。
まだ「注目コンテンツを表示しないとサイトとして不足」という状態ではない。
アクセスデータを持つようになったことで、読まれている記事を次の導線へ使えるようになった、という位置づけになる。
関連記事も同じ。
記事が増えるほど「この次に読むならこれ」という候補は増える。
本文の中で直接つながる記事は手動でリンクし、一覧として見せたい関連情報はカテゴリやタグから出す、と役割を分けた方が管理しやすい。
増えたときに必要なものと、データから欲しくなるものを分ける#
今のゆまラボで起きたことを分けると、次のようになる。
| 記事が増えて必要になったもの | データが見えて欲しくなったもの |
|---|---|
| カテゴリ・サブカテゴリ | 注目コンテンツ |
| 連載管理 | 人気記事ランキング |
| タグの正規化 | 流入元別の分析 |
| ページネーション | 関連記事の出し分け |
| サイト内検索 | 読まれている記事からの次の導線 |
| パンくず・内部リンク | 更新候補の判断 |
| sitemap・リンク切れ確認 | アクセスデータを使った自動表示 |
前者は、記事数が増えるほど手作業では維持しにくくなる部分。
後者は、アクセス解析を始めたことで判断材料が増え、そのデータをサイトへ戻したくなる部分。
両方を一度に実装する必要はない。
記事が5件の段階で人気記事ランキングや複雑な関連記事ロジックを作っても、使えるデータが少ない。
逆に記事が増えているのに、カテゴリ名やタグを毎回手入力だけで管理していると、後から直す量が増える。
AstroではContent CollectionsのFrontmatterを共通データとして使えるので、
記事を書く
↓
Frontmatterを検証
↓
カテゴリ・タグ・連載へ自動反映
↓
一覧・検索・sitemapへ反映
↓
ビルド時に問題を検出という形に寄せやすい。
アクセス解析側も、
アクセスデータを蓄積
↓
必要な指標を決める
↓
人気記事などに使う
↓
可能ならData APIで自動化と段階を分けられる。
記事数が増えると、必要なのは「機能をたくさん付けること」ではなく、記事を1本追加したときに手作業で直す場所を増やさないことになる。
ゆまラボでも、分類、検索、タグ、内部リンク確認、画像処理などは、記事数が増えてから同じ修正を繰り返さないための共通処理へ少しずつ置き換えてきた。
アクセス解析から出てきた「注目コンテンツ」は、その次の段階になる。
参考#
関連記事
第4回 Google Analyticsをゆまラボへ導入する―GA4を設定してリアルタイム計測まで確認
Google Analyticsを初めて設定し、ゆまラボ用のGA4プロパティとWebデータストリームを作成。AstroへGoogleタグを追加してCloudflareへ反映し、リアルタイムレポートでアクセスが入るところまで確認した記録です。
GA4に自分のアクセスはどれくらい混ざるか―内部トラフィックの確認と除外方法
ゆまラボのGA4導入直後に自分で開いたページも計測された経験から、自分のアクセスを後から判別できるのか、内部トラフィックをIPで定義して除外する手順とデメリットを確認する。
第3回 人気記事を自動表示したい―Cloudflareでも見られるがGoogle Analyticsを使うことにする
ゆまラボのトップページに直近30日の人気記事を自動表示するため、Cloudflare Web Analyticsで現在見られるデータを確認し、今後の分析やData APIでの自動取得を考えてGoogle Analyticsも使うことにした。