本文へスキップ
合同会社ギャラクタス Site Architecture galactus.co.jp 相談する
  1. ホーム
  2. サイトアーキテクチャ

galactus.co.jp

Galactus
Site Architecture
ギャラクタスのサイトアーキテクチャ

サイトの「仕組み」も、公開しています。

ギャラクタスのWebサイトは、ページを組み立てるAstroと、記事を書くためのWordPressを組み合わせて動いています。使っている技術とその理由、記事が公開されるまでの流れを、実際の設定とともに公開します。ページ内の数字は、ビルドのたびにソースコードとWordPressから読み取っています。

シンボルマークを囲むひし形と、サイトを支える4つの層 WordPress 書く Astro 組み立てる GitHub Actions 届ける Static HTML 表示する
ページのテンプレート
150
共通コンポーネント
27
ビルド時に取り込む記事
272
本番で使うパッケージ
3
無料のWebツール
24

01Principles

速く、安全に、更新しやすく。

小さな会社のWebサイトは、少ない人数で長く運用していくものです。だからこそ、表示の速さと安全性、そして記事の更新しやすさを、仕組みの側で支えることにしました。技術を選ぶときは、次の4つを基準にしています。

  • 静的に書き出す

    ページはすべて、公開する前にHTMLとして書き出しておきます。アクセスのたびにサーバーで組み立てないので表示が速く、攻撃の入り口になる部分も減らせます。

  • 書く人の道具は、そのまま

    記事は、使い慣れたWordPressの管理画面で書きます。見た目をつくる仕組みとは切り離しているので、書く人はデザインを気にせず更新できます。

  • 持ち物を少なく

    本番で使うパッケージは3つだけ。画面の部品をつくるためのJavaScriptフレームワークは使わず、HTMLとCSSの標準でできることは標準で書きます。

  • 人の注意力に頼らない

    記事が取得できない、デザインの値が読めないといった異常は、ビルドの時点で止めます。間違ったページを公開するより、公開しないほうを選びます。

02Tech Stack

使っている技術

それぞれの技術を、何のために、なぜ選んだのか。バージョンの表示は、ビルドに使ったものをそのまま読み取っています。

  • Astrov5.18.2

    ページを組み立て、静的なHTMLに書き出す

    必要なところにだけJavaScriptを読み込むので、表示が軽く保てます。

  • WordPress

    ブログ・お知らせ・制作実績を書いて管理する

    管理画面はそのままに、表示はAstro側で自由につくれる「ヘッドレス」な使い方をしています。記事はREST APIで受け渡します。

  • TypeScriptv5.9.3

    データの受け渡しや、ビルド時の処理を書く

    WordPressから届くデータの形を型で決めておき、取り違えを防ぎます。

  • Sassv1.101.0

    スタイルを書く(FLOCSSで整理)

    デザイントークンからCSSを組み立てます。値の一覧はデザインシステムで公開しています。 デザインシステム

  • Pagefindv1.5.2

    サイト内検索

    ビルド時に索引をつくっておくので、検索のためのサーバーやデータベースがいりません。

  • GitHub Actions

    ビルドと公開を自動で行う

    誰が操作しても、同じ手順・同じ環境で公開できます。

  • Contact Form 7

    お問い合わせフォームの受付とメール送信

    静的なページから、WordPressのフォーム機能へ直接送信します。

  • Cloudflare Turnstile

    不正な送信の防止

    画像を選ぶような操作を求めずに、ロボットによる送信を見分けます。

03Architecture

書く場所と、見せる場所を分ける。

記事を書くWordPressと、訪問者が見るWebサイトを切り離しているのが、この構成の要です。WordPressは記事の保管庫に徹し、表示はAstroが書き出した静的なファイルが担います。

Source

WordPressブログ・お知らせ・制作実績

GitHubページ・デザイン・機能のコード

Build

GitHub Actions自動でビルドを始める

Astro + PagefindHTMLと検索用の索引をつくる

Delivery

Webサーバーできあがったファイルを返す

訪問者のブラウザページを表示する

フォームの送信だけは、ブラウザからWordPressへ直接届きます(フォームのしくみ)。

04Content Flow

記事がページになるまで

WordPressで記事を公開してから、Webサイトに表示されるまでの流れです。すべて自動で進み、保存からおよそ5~10分で公開されます。

  1. WordPressで記事を公開する

    管理画面で記事を公開・更新・削除します。予約投稿も、公開の時刻になると同じ流れに乗ります。

  2. GitHubへ自動で知らせる

    WordPressに組み込んだ小さなプラグインが、記事が変わったことをGitHubに伝えます。

  3. 最新の記事を受け取る

    GitHub Actionsが起動し、REST APIからブログ・お知らせ・制作実績をまとめて受け取ります。

  4. ページを書き出す

    Astroが一覧と詳細ページ、RSS、サイトマップを生成し、Pagefindが検索用の索引をつくります。

  5. サーバーへ配置する

    書き出したファイルを本番のサーバーへ送ります。ここまで、人の操作はいりません。

このページのビルドで取り込んだ記事

ブログ
97件
お知らせ
112件
制作実績
63件

05Pages

ページのつくり方

会社案内やサービス、料金などの固定ページは、WordPressではなくコードとして書いています。変更の履歴がすべて残り、公開の前に確認用の環境で見た目を確かめられるからです。

ファイルの場所が、そのままURLになる

src/pages/company/features.astro というファイルは、/company/features/ というURLのページになります。新しいページは、次の形から書き始めます。

---
import PageLayout from '@/layouts/PageLayout.astro';

const title = 'ページタイトル';
const description = 'このページだけの説明文(80~120字)';
---

<PageLayout title={title} description={description}>
  <section class="page_section">
    <h2 class="page_section_title">見出し</h2>
    <p>本文は、そのままHTMLで書きます。</p>
  </section>
</PageLayout>

4つのレイアウト

PageLayout
標準の固定ページ。ヘッダー・フッター・パンくず・相談の導線までが入ります。
SidebarLayout
サイドバーのあるページ。課題解決や用語集、記事の詳細に使います。
LpLayout
独立したデザインのランディングページ。サイト共通のヘッダーやCSSを読み込みません。このページもこのレイアウトです。
StudioLayout
無料のWebツール「Studio」専用のレイアウトです。

決めていること

  • 本文は素のHTMLで書き、コンポーネントにするのはヘッダーやフォームなどの共通部品だけにする
  • title と description は全ページで別の文にする(description は80~120字)
  • 画像には width・height と、内容を伝える alt を付ける
  • ランディングページのスタイルは、ページごとに独立させる

見た目のルールはデザインシステム、文章のルールはライティングガイドラインにまとめています。

数字で見るこのサイト

ページのテンプレート
150記事の一覧や詳細は、1つのテンプレートから生成
共通コンポーネント・レイアウト
32ヘッダー・フッター・フォーム・カードなど
無料のWebツール「Studio」
24同じリポジトリで開発・公開

同じ仕組みで動いているツール集Studio

06Forms

フォームのしくみ

静的なWebサイトは、それだけではフォームを受け付けられません。お問い合わせや見積もりのフォームは、WordPressのフォーム機能に送信を任せています。

  • 送信はREST APIで

    ページは静的なまま、受け付けとメールの送信はWordPressのContact Form 7が担当します。

  • 不正な送信を防ぐ

    Cloudflare Turnstileで、ロボットによる送信を確認します。多くの場合、送る方に余計な操作は求めません。

  • フォームの中身もコードで管理

    入力項目、通知メール、自動返信の文面を、リポジトリのファイルとして管理しています。変更前にWordPress側との差分を確かめてから反映します。

  • 見た目は共通の部品で

    入力欄やエラー表示は、デザインシステムのフォーム部品をそのまま使っています。 デザインシステム:フォーム

実際のフォームお問い合わせ

07Deploy

記事は自動で、コードは確かめてから。

記事の更新と、ページやデザインの変更とで、公開までの道を分けています。記事はすぐに届けたいので自動で。コードの変更は見た目や動きに関わるので、必ず人が確かめてから公開します。

記事の更新自動

  1. 管理画面で公開
  2. 自動でビルド
  3. 本番に反映

保存から5~10分ほどで公開されます。

ページやデザインの変更人が確認

  1. コードを送る(push)
  2. 確認用の環境に自動で公開
  3. 表示を確かめる
  4. 手動で本番に反映

確認用の環境は、パスワードで保護しています。

コードを送っただけでは、本番は更新されません。確かめていない変更が、うっかり公開されないようにするためです。本番のデプロイが動くきっかけは、次の2つだけです。

# 本番へのデプロイ(.github/workflows/deploy-production.yml より抜粋)
on:
  repository_dispatch:
    types: [content_updated]   # WordPressで記事が変わったとき
  workflow_dispatch:           # 人が手動で実行したとき
# コードを送った(push)だけでは、本番は動かない

08Safeguards

間違ったページは、公開しない。

自動化は便利な反面、異常に気づかないまま公開してしまう危うさもあります。そこで、おかしなことが起きたときは「止まる」ように作っています。

  • 記事が取れなければ、公開しない

    ビルドの最初に、ブログ・お知らせ・制作実績がそれぞれ1件以上取得できるかを確かめます。取れないときはビルドを中止し、直前の正常な本番をそのまま残します。

  • デザインの値が読めなければ、公開しない

    デザインシステムのページは、SCSSの値をビルドのたびに読み取って描画しています。読み取れない値があればビルドを失敗させ、古い情報のまま公開されるのを防ぎます。 デザインシステム:しくみ

  • WordPressの本体には触れない

    サーバーへ配置するときは、WordPressのファイルを対象から外しています。サイトを更新しても、CMSが壊れることはありません。

  • 内部リンクを点検する

    ページ同士の関連リンクが切れていないかを、スクリプトでまとめて確認できるようにしています。

  • 毎回、まっさらな環境でビルド

    ビルドはいつも同じ環境で、何もない状態から行います。手元のパソコンの違いで、結果が変わることはありません。

09Performance

表示の速さ

ページが表示されるまでの数秒は、訪問者がそのまま帰ってしまうかどうかを左右します。速さのために、次のことをしています。

  • できあがったHTMLを返すだけ

    アクセスがあったときにサーバーがすることは、用意済みのファイルを返すことだけです。

  • 画像の場所を先に確保

    すべての画像に幅と高さを書き、読み込みの途中でレイアウトがずれないようにしています。画面の下のほうの画像は、近づいてから読み込みます。

  • 検索も静的に

    サイト内検索は、必要な部分の索引だけをその場で読み込みます。検索のたびにサーバーへ問い合わせることはありません。

  • アイコンのちらつきを抑える

    アイコン用のフォントが届くまでは、アイコンを表示しません。読み込みの途中で、アイコン名の文字が見えてしまうのを防ぎます。

  • CSSはまとめて、ページごとに分ける

    サイト共通のCSSは1つのファイルにまとめ、ランディングページは自分のCSSだけを読み込みます。

10Search Engines

検索エンジンへの配慮

検索エンジンに正しく理解してもらうための情報は、ページごとに書き忘れることがないよう、レイアウトの側で自動的に出力しています。

  • メタ情報は自動で

    タイトル、正規URL、シェア用の画像と説明文を、全ページで同じ形式で出力します。ページ側で書くのは、タイトルと説明文だけです。

  • 構造化データ

    全ページに会社の情報(住所・営業時間)とサイト内検索の情報を、記事のページには記事の情報を、検索エンジンが読める形で添えています。

  • サイトマップの更新日は「本当に変わった日」

    各ページのソースが最後に変更された日を、サイトマップの更新日にしています。ビルドした日を一律に入れると、検索エンジンに更新日そのものを信用されなくなるためです。

  • RSSを配信

    ブログとお知らせは、RSSでも読めるようにしています。

  • 移ったURLは引き継ぐ

    旧サイトから変わったURLは、恒久的なリダイレクト(301)で新しいページへ案内します。

タイトルと説明文の書き方ライティングガイドライン:検索とSNS

Work with us

長く使える仕組みで、
あなたのWebサイトを。

ギャラクタスは、大阪・阿倍野のWeb制作会社です。このサイトと同じように、公開したあとの更新や運用まで見すえて、ホームページの制作から保守・運用までお手伝いしています。