移行先の比較更新日
#StudioのブログをAstroのMarkdownへ移す手順は？
どこから手を付ければいいのか。最初の作業は、Studioの外から記事を集めることです。StudioではデザインやCMSデータの書き出しができません。そのため、公開サイトに出ている記事を一本ずつ拾っていくことになります。
大まかな流れは次のとおりです。
- サイトのドメインの末尾に「/sitemap.xml」を付けたアドレスをブラウザで開き、記事のURLを書き出す
- 各記事ページから、タイトル、公開日、本文、画像を集める
- 本文のHTMLをMarkdownに変換し、先頭のfrontmatterにタイトルや公開日を書く
- Astroのコンテンツコレクションに記事を入れ、記事ページ用の動的ルートを作る
- 旧URLと新URLの対応表を作り、公開前に表示を確かめる
サイトマップに全記事が載っているとは言い切れません。StudioのCMS画面に出ている記事数と照らし合わせて、漏れを探しておきましょう。
つまずきやすいのは4つ目です。コンテンツコレクションにMarkdownを置いただけではページURLが生成されないため、getStaticPaths()を使って各記事のパスを生成する実装を行います。
frontmatterに slug を書くと、自動で付く記事IDをその値に置き換えられます。本文に貼っていた画像やPDFも、忘れずに移す対象に入れてください。記事のテキストだけ移して、画像は旧サイトのURLを参照したままという状態は避けたいですね。
#AstroのルーティングでStudioの旧URLを再現できますか？
たとえば、Studioで公開していた記事のURLが「/posts/marketing-guide」だった場合、Astro側でもまったく同じ階層と文字列を再現できます。Studioの動的ページはパスの末尾に「:slug」が割り当てられ、CMSアイテムごとに設定した文字列がURLに反映される仕組みです。Studioのスラッグは、記事を作ったときに自動で付き、あとから好きな文字列に変えられます。人によって付け方がばらばらなので、推測で組み立てず、サイトマップに出ている実際のURLから拾うほうが安全でしょう。
ドメインもパスも同じままなら、読者から見たURLは変わりません。この場合はURLを変えない引っ越しとして扱われ、DNSの切り替えと動作確認が中心になります。
一方、これを機にスラッグを読みやすく変えるなら、旧URLから新URLへの転送が必要です。転送には、可能なら301か308のサーバー側の恒久リダイレクトを使います。
気をつけたいのはAstroの redirects 設定です。HTMLファイルとして書き出す場合、サーバーがステータスコードを返すわけではなく、meta refreshによる転送になります。301を返したいなら、アダプターがホスト用の設定を書き出せるか、配信先で転送ルールを設定できるかを確かめてください。
#Markdownにした記事をAstroのContent Collectionsで管理するには？
単にフォルダ内のMarkdownファイルを直接読み出す従来の方法と比べ、AstroのContent Collectionsを使うと、記事データの検証とTypeScriptによる型チェックをまとめて扱えるようになります。
管理の基本となるのが、設定ファイル「src/content.config.ts」の作成です。ここでdefineCollection()とglob()を組み合わせてローカルのMarkdownファイルを読み込みます。Content Collectionsの仕組みでは、glob()ローダーのbaseとpatternを調整すればプロジェクト内の自由な場所に記事ファイルを置けるため、記事の管理方針に応じたディレクトリ配置を選べますね。スキーマ定義では、記事タイトルや説明文の文字列型、公開日の日付型などを指定します。
Studioのプロパティをどう置き換えるかは、記事を変換する前に決めておきましょう。テキストや数値はそのまま文字列や数値にできます。ただ、他のモデルを結び付ける参照プロパティは、ただの文字列とは別物です。タグやカテゴリーなら、スラッグの配列に置き換えるのが扱いやすいでしょう。
一覧画面を作る際はgetCollection()を使って記事データを取得します。ここで注意したいのは、取得した配列の並び順が自動で日付順にはならない点です。公開日の新しい順に並べたいときは、JavaScriptのsort()関数を使って日付順に並べ替えましょう。詳細ページではrender()から取得したContentコンポーネントを配置して本文を出力します。
schemaに合わない記事があれば、Astroはエラーを出して止まります。必須にした公開日が抜けている記事は、ここで見つかりますね。一方、ページ側のコードの型エラーは通常のビルドでは調べないため、astro check を別に走らせてください。
#AstroでCMSを使わずMarkdownだけで更新していけますか？
管理画面のボタン操作に慣れていた場合、CMSを使わずにMarkdownファイルだけで日々のブログ更新を続けられるのでしょうか。結論として、記事の執筆から公開までの流れを一度整えてしまえば、Markdown単体でも問題なく更新を回せます。
Astroは標準機能としてMarkdownの解析やレンダリングを備えているため、特別なプラグインを導入しなくても記事を増やせます。手元のテキストエディタでファイルを新規作成し、タイトルの記述や見出しの装飾をMarkdownの書式で入力していくだけです。画像の貼り付けも、画像をフォルダに保存して指定のパスを書き込むだけで完了します。
公開の手間も、最初に一度設定すれば小さくなります。たとえばCloudflare PagesとGitを連携しておけば、記事を追加してプッシュするたびにビルドと公開が自動で走りますね。毎回手元でビルドしてファイルをアップロードする必要はありません。
もし社内にGitやMarkdownの操作に不慣れな担当者がいる場合は、Git連携型のDecap CMSなどを後から追加する手もあります。これを使えば、管理画面から文字を入力するだけで裏側のリポジトリへ変更が記録されます。導入には別途設定が必要です。
もうひとつ、Astroはサーバー側で動的にページを作る機能も持っています。Astroを選んだからといって、自動的に静的ファイルだけのサイトになるわけではありません。ブログをMarkdownだけで回すなら、静的出力のままで組めます。
こんな聞き方も
- StudioのブログをAstroのMarkdownブログへ移行できますか？
- astro markdown ブログ 移行
- astro content collections 移行
- Markdownにした記事をAstroのContent Collectionsで管理するには？
- astro ルーティング 旧 url 再現
- AstroのルーティングでStudioの旧URLを再現できますか？
- astro markdown 更新 cms なし
- AstroでCMSを使わずMarkdownだけで更新していけますか？
あわせて知りたい（関連する疑問）
QStudioの記事の画像を一括でダウンロードできますか？
1枚ずつ手動で右クリックして保存していく方法もありますが、記事数が多いときは別の方法を使ったほうが早く済みます。Studioにアップロードした画像は、アセットパネルにまとまっています。ただ、ここから画像をまとめてダウンロードできる機能は、ヘルプでは案内されていません。
そこで現実的な解決策となるのが、公開中のWebサイトを巡回して手元にデータを保存するツールの利用です。HTTrackの配布ページなどで配布されているサイト巡回ツールを活用すると、公開サイトの階層をたどり、HTMLファイルや掲載画像をローカル環境へまとめてダウンロードできます。とはいえ、Studioのページで画像がすべて取れるか、元のサイズのまま保存されるかは、実際に試して確かめるしかありません。保存できた画像の解像度は、記事に使うサイズと見比べておいてください。集めた画像はAstroのプロジェクト内に置き、Markdown本文の画像パスを新しい場所に書き換えます。
もう一点、画像のURLも見ておきましょう。WordPressから取り込んだ記事や、他のサイトからコピーした画像は、Studioではなく外部サーバーを参照していることがあります。参照元が消えると、Studio上でも表示されなくなります。
QStudioの記事のカテゴリやタグも移せますか？
StudioのCMSで設定していたカテゴリやタグなどの分類情報は、AstroのMarkdownブログへ問題なく引き継げるのでしょうか。カテゴリ名やタグ名を移すこと自体はできます。ただし自動ではなく、記事ごとに書き写す作業が要ります。
Studioでは、タグやカテゴリごとの一覧ページを組み立てる際に参照プロパティを利用します。これは別のモデルで作成したアイテムを記事に結び付ける仕組みで、単なるテキスト入力とは異なる管理が行われています。公開ページから集めるときは、記事ページに出ているタグ名やカテゴリ名を拾い、それをMarkdownのfrontmatterに書き込みましょう。
StudioのCMSアイテムは、公開ステータスの説明のとおり、ステータスが「公開中」のものしか公開サイトに出ません。非公開の記事や下書き状態のアイテムはWeb上に出力されないため、移行漏れを防ぐには管理画面のアイテム一覧と突き合わせて確認します。
QWordPressのWXRのような移行ファイルはStudioから出せますか？
WordPressならツールのエクスポートから記事一式のXMLを出せるので、Studioにも似た機能があるはずだと探す人は多いようです。
答えは、出せません。StudioにはCMS記事やページ情報、デザイン、ソースコードを外部ファイルとして出力するエクスポート機能は存在しません。問い合わせフォームの回答であればCSVファイルとして手元に保存できますが、ブログ記事の本文や投稿データはダウンロードの対象外となっています。
少しややこしいのは、WordPressからStudioへ移る方向の機能は用意されている点です。StudioはWordPress標準のWXRファイルを取り込むインポート機能を備えているため、逆方向の書き出しもできると勘違いされやすい一面があります。WordPress側ではWP-CLIの export コマンドでWXRを出せますが、これもWordPressの機能です。
ヘルプでも、書き出せないデータは移行先で作り直すよう案内されています。つまり、移行ファイルにあたるものは自分で作ることになります。Astroへ移す場合は、記事ごとのMarkdownファイルそのものがその役目を持ちます。frontmatterにタイトル、公開日、スラッグ、タグを入れておけば、あとで別のサービスへ移るときにも使い回せるファイルになります。
Q記事が100件以上あっても移行できますか？
公開している記事が100件以上ある場合でも、Astroへ支障なく移行できるのでしょうか。結論から言えば、移行はできます。鍵になるのは、記事を取り出して変換する作業をどう効率よく進めるかです。
Astroのコンテンツコレクションは、ビルド時のデータをキャッシュする仕組みを備えており、数万件規模の記事データを扱う用途にも適しています。件数だけでビルドが止まるとは考えにくいものの、移す件数で一度ビルドして確かめましょう。
移行で課題になるのは、Studioから記事を移し替える作業量です。公式のエクスポート機能がないため、記事は公開ページから集め直すことになります。件数が多いときは、作業をスクリプトに任せます。サイトマップから記事URLを集め、各ページのHTMLを取得し、本文の部分だけを取り出して、Turndownのような変換ライブラリでHTMLをMarkdownにする、という流れです。タイトルや公開日もページから拾い、frontmatterとして書き込みます。
ただ、自動変換の出来はページの作りに左右されます。表、埋め込み動画、SNSの投稿、装飾した見出しなどは崩れやすいので、変換後に何件か開いて、元の記事と見比べてください。崩れ方に共通点があれば、変換ルールを直してから全件を流し直したほうが早く済みます。
あわせて、移転前のURL一覧を作成し、新しい記事パスとの対応表を整理しておきましょう。スラッグをそのまま引き継ぐなら対応表は単純になり、確認する箇所も少なくて済みます。
この内容をChatGPTで相談
