microCMSにはフォーム機能がありますか？
「Studioのように管理画面を開けば、最初からお問い合わせフォームの受信箱が用意されているのだろうか」と探してしまう人は少なくありません。しかし、microCMSには専用の受信トレイやフォーム管理機能が標準で組み込まれていません。microCMSは入稿された文章や画像をAPI経由で配信することに特化した仕組みだからです。ただ、フォームを作れないわけではありません。microCMSのお問い合わせフォーム案内では、POST APIで管理画面の外からコンテンツを登録できる仕組みを使い、送られた内容をmicroCMSに保存する方法が紹介されています。GoogleフォームやHubSpotのような外部サービスのコードを埋め込む方法も同じページにあります。
もっとも、microCMSの管理画面は顧客対応や問い合わせの進捗管理に向けて最適化された画面構成ではありません。問い合わせの件数が多く、未対応や対応中といったステータスを細かく管理したい場面では、POST APIによる自前運用は合わないことがあります。
ちなみに、Studioでフォーム回答をSlackに流していた人は、Googleスプレッドシートと Google Apps Script を間に挟んでいたはずです。移行後はその経路も作り直しになるので、通知先も一緒に洗い出しておくと抜けがありません。
microCMSのサイトに付けるフォームの選択肢は？
では、microCMSで構築したサイトにお問い合わせを設けるには、どのような選択肢があるでしょうか。どれを選ぶかは、サイトの作り、問い合わせの件数、かけられる費用と作業の時間で変わります。大きく分けると次の3つです。
| 選び方 | 例 | 向いている人 |
|---|---|---|
| フォームサービスを埋め込む | formrun、Googleフォーム | コードを書かずに早く置きたい |
| 送信だけを外部に任せる | Formspree | 見た目は自分で作り、受け取りは任せたい |
| 送信処理を自前で書く | Cloudflare Workers と Resend | 処理やメール文面まで決めたい |
埋め込み型は、サービス側で作ったフォームをiframeでページに貼る方法です。Studioのときの手軽さに近いですね。
2つ目は、Formspreeのようなフォーム処理サービスをAPIとして呼び出す方法です。Formspreeの料金プランでは、無料プランはテストや開発向けと案内されています。本番でまとまった件数を受け取るなら有料プランを視野に入れます。
3つ目は、Cloudflare Workersなどのサーバーレス環境からResendを利用してメールを送る仕組みを組む方法です。入力欄のデザインもエラーの出し方も自由になる一方、回答をどこに残すか、スパムをどう弾くかまで自分で決めることになります。
Studioのフォームを移すとき、何を決めておけばいいですか？
「Studioで動いていた項目をそのまま移行先へコピーすれば完了だろうか」と考える人は多いかもしれません。ところが実際には、回答の行き先や保存の扱いのほうがあとで困りやすい部分です。
まず、Studioのフォームでは、項目ごとに必須かどうかを選べ、テキスト、メールアドレス、電話番号といった入力の種類も分けていました。移す前に、項目名と必須の設定、入力の種類を一覧にしておきます。新しいフォームでも同じ入力規則を再現できるか、本当に必要な項目に絞り込めるかを見直します。
もうひとつ決めておきたいのが、回答をどこに残すかです。Studioでは回答の保存を無効にしてスプレッドシート連携も外していれば、回答は通知先のメールにだけ届いていました。2026年10月のStudioの不正アクセスに関するお知らせでは、保存を途中で無効にしても、それまでの回答は完全に削除するまで残り、流出した可能性のある範囲に入ると説明されています。保存を無効にしていた間の回答や通知メールの内容はStudioに残っていません。新サイトでも、回答データをデータベースへ溜めるのか、それともメール通知だけに留めて保存先を絞るのかを最初に決定しておきたいところですね。
さらに、スパム対策の設計も外せません。microCMSへブラウザから直接POSTする設計は、独自の防御処理を途中に挟めなくなるため通常は推奨されていません。どの組み方が正解という決まりはなく、要件と担当できる人の時間で選ぶことになります。
StudioからmicroCMSへ移行するとSEOに影響はありますか？
CMSをStudioからmicroCMSへ切り替えると、検索順位や流入数にどのような変化が起こるでしょうか。影響は出ます。サイトを大きく作り替えると、Googleがページを読み直して登録し直すまでの間、順位が上下することがあります。URLや文章をそのまま残しても、順位が保たれる保証はありません。
ページのURLが変わるなら、旧URLから新URLへの301リダイレクトを用意します。GoogleのURL変更を伴うサイト移転の手順のとおり、すべての旧ページをトップページへ一括で飛ばすような処理は避け、対応する個別ページへ転送しましょう。ただし、複数の古いページを1本の濃い記事へ集約した場合は、その統合先URLへリダイレクトを束ねても問題ありません。リダイレクトはできるだけ長く、目安としては1年以上残すよう勧められています。Studioで設定していた転送が新しいホスティングでも動いているかは、公開後に旧URLを開いて確かめてください。
新サイトを本番公開した後は、開発環境で設定していたアクセス制限やクロール拒否の記述が残っていないかを点検し、Search ConsoleのURL検査ツールでGooglebotが正常に到達できているかを確かめます。
また、microCMSのようなヘッドレスCMSでは、ページをどう作って配信するかを自分で選びます。ビルド時にHTMLを作るのか、アクセスのたびに作るのか、ブラウザで組み立てるのか。この選び方も検索での見え方に関わるので、制作を頼むなら最初に聞いておきたいところですね。
microCMSのサイトでSEO対策はフロントエンド側で何をすればいいですか？
たとえばNext.jsで作るなら、ページのtitleやdescriptionは metadata か generateMetadata で設定します。後者を使えば、microCMSから取ってきた記事タイトルや抜粋をもとに、記事ごとのメタ情報を出せますね。microCMSはサイトの表示部分を持たないので、こうしたメタ情報はすべて使うフレームワーク側で書くことになります。
重複コンテンツによる評価の分散を防ぐため、正規URLを示すrel="canonical"タグの出力も欠かせません。Next.jsであればalternates.canonicalの項目から指定できます。GoogleのJavaScript SEO基本方針でも警告されている通り、canonicalタグが競合していたり複数記述されていたりすると検索エンジンが意図しない解釈をしてしまいます。
検索に載せたいページでは、最初に返すHTMLに noindex を入れないでください。Googleは noindex を見つけるとJavaScriptの実行を飛ばすことがあり、あとからスクリプトで消しても効かない場合があります。
サイトマップについては、Astroであれば公式のsitemapインテグレーションを組み込むことで、動的ルーティングで生成された記事ページも含めてビルド時にxmlファイルを出力できます。構造化データのJSON-LDも画面側で正しく埋め込み、テストツールで構文を確認しましょう。