Astroのサイトで、誰が何を更新できますか？
日常のブログ記事やお知らせを更新するたびに、毎回エンジニアへ作業を依頼する必要があるのでしょうか。
Astroで作られたWebサイトでも、コンテンツ管理システム（CMS）をあらかじめ接続しておけば、日々の記事作成やテキストの修正は編集担当者が管理画面から行えます。microCMSとAstroの連携手順でも、入稿した内容を書き換えるとサイト上の記事も変わる流れになっていました。そのため、日常的な広報記事やブログの追加であれば、非エンジニアのスタッフだけで問題なく作業を進められますよ。
ただし、入力と表示は別々に作られています。CMS側では「タイトル」「本文」「サムネイル」といった入力欄を決め、どの欄をどこにどう並べるかはAstroのコードで指定します。決まった欄に文章や画像を入れるだけなら、担当者だけで済みますね。入力欄を増やしたい、並び順やデザインを変えたいとなると、コードを触れる人の出番です。
新しいページの追加も、ひとまとめに「エンジニアが必要」とは言えません。Astroのページルーティング仕様では、あらかじめ用意した雛形ファイルにCMSのデータを当てはめて複数のページを自動生成する仕組みを取っています。だから、CMS側で新しい項目の作成を許可しておけば、記事やお知らせのように形が決まったページは担当者が増やせます。雛形そのものを新しく作ったり、共通ヘッダーのデザインを改修したりする作業には、HTMLやCSSを中心に、Astroのコンポーネントを書く知識が要ります。
いま社内で更新している箇所を、「決まった欄に入れるだけのもの」と「見た目や項目を変えるもの」に分けて書き出します。前者がほとんどなら日々の更新は社内で回せますが、後者は移行後も外部に頼む作業として残ります。
Astroのサイトを非エンジニアが更新できるGitベースのCMSはありますか？
ヘッドレスCMSは、記事の置き場所で大きく2つに分かれます。記事をサイトのファイルと一緒にGitのリポジトリ（ファイルの保管庫）へ保存するGitベースと、CMS事業者のサーバーに保存し、APIという窓口から取り出すAPIベースです。どちらも管理画面から編集でき、GitベースのCMSもヘッドレスCMSの一種に入ります。
こうしたGitベースのCMSの中には、非エンジニアでもブラウザの管理画面から直感的に更新できるツールが揃っています。代表例がDecap CMSやKeystaticです。Decap CMSを導入すると、編集担当者はGitのコマンドやソースコードの書き方を意識することなく、通常のブログ作成画面と同じ感覚でテキストの執筆や画像の挿入を行えます。管理画面で保存を実行すれば、リポジトリに変更が自動で記録される仕組みです。
KeystaticはGitHubか手元のファイルを直接編集する方式で、データベースを持ちません。MarkdownのほかYAMLやJSONも扱え、MarkdocやMDXといった拡張形式にも対応しており、編集者は見やすい管理画面から、開発者は手元のコードエディタから同じコンテンツを触れます。さらに、Astroの公式ドキュメントにはCloudCannonやTina CMS、Front Matter CMSなども掲載されています。
一方、APIベースの代表が日本製のmicroCMSです。アカウント登録とログイン、サービスの作成までは画面上で進み、そのあと入力欄の設定とAstro側への組み込みを行います。
どの方式を選んでも、担当者が日々の記事を書く分にはGitの知識はいりません。ただ、管理画面を使える状態にする最初の設定や、入力欄の作り込みは制作側の作業として残ります。
Astroでサイトマップを生成して送信するには？
StudioからAstroへサイトを移行した際、検索エンジンのクローラーに巡回を促すXMLサイトマップはどのように作成すればよいのでしょうか。
Studioでは、サイトのドメイン直下の /sitemap.xml にサイトマップが自動で用意されていました。Astroでは公式の統合パッケージが提供されており、手作業でXMLファイルを作る必要はありません。まず、サイトマップ用インテグレーションを入れて、ビルドのたびに作らせます。手順は次のとおりです。
- ターミナルで
npx astro add sitemapを実行し、@astrojs/sitemapを追加する（コマンドは同じ公式ページの手順で確認する） - astro.config.mjsの
siteに公開先のURLを書く（http:// か https:// で始める） astro buildを実行し、出力先にsitemap-index.xmlとsitemap-0.xmlができているか確かめる- 公開後、Google Search Consoleにsitemap-index.xmlのURLを送る
生成されたファイルのうち、同じ公式ページの説明では、全体のまとめ役は sitemap-index.xml なので、送信はこのファイルにしておくのが無難でしょう。Studio時代のsitemap.xmlとはファイル名が変わるため、Search Consoleに古いURLを登録したままなら、新しいURLを追加しておきたいところです。
ただし、サーバー側でアクセスごとにページを動的に組み立てるSSRモードの動的ルートについては、この機能で自動生成されない点に注意してください。事前に書き出すページがサイトマップに入っているかは、ビルド後のsitemap-0.xmlを開いて確かめておきましょう。
また、Googleへのサイトマップ送信は検索エンジンに対するヒントの通知であり、送信したURLがすべて取得されたり検索結果に反映されたりする結果を約束するものではありません。
Astroで日本語Webフォントを軽く読み込むには？
日本語サイトで手軽に効くのは、Webフォントを見出しだけに使い、本文は端末に入っているシステムフォントに任せる方法です。Astroでは見出しにだけWebフォントを当てられるので、本文用フォントのダウンロードがまるごと減ります。
日本語を含むフォントは収める文字が1万を超える場合があり、英語のフォントよりファイルが大きくなることがあります。Webフォントを使う場合も、読み込む太さを絞ります。Astroでは実際に使うウェイトとスタイルだけを指定でき、Google Fontsでも必要な太さだけを要求できます。見出し用に2種類ほどに抑えるのが、実装でよく取られる目安です。
固定のキャッチコピーや大見出しのように、使う文字が事前に決まっている箇所では、必要な文字だけを指定して読み込みます。Google Fontsを利用する場合、配信URLの末尾にtext=パラメータを付与し、表示させたい文字列だけを限定して要求すれば、転送量を大幅に圧縮可能です。ただし、記事タイトルのように中身が毎回変わる場所には向きません。
表示の待ち時間には font-display: swap も使えます。フォントの読み込み中も代替フォントですぐに文字が表示されるため、画面が真っ白のまま待たされる現象を回避できます。もっとも、容量は減らないうえ、切り替わりのタイミングでレイアウトがずれることもありますね。
ちなみに、StudioではGoogle Fonts、TypeSquare、システムフォントを標準で使えました。とはいえ、自社サーバーからフォントを配信したり文字を間引いて加工したりする際は、利用規約やライセンスがその改変行為を認めているか必ず確認してください。