読み方の1ポイント
目的、対象、確認項目を分けて読む
このページでは、Codex作業を安全に進めるための考え方を整理します。実行前に、対象、触らないもの、確認項目を分けて見ると迷いにくくなります。
このページも、全部を一度に覚えないとダメ？
必要なところから読めば大丈夫です。作業前に対象と停止条件、作業後に確認項目を見ると安全です。
何ができるページか
Codexを使ってWordPressサイトをコード版へ移行する時に、index.phpや.htaccessを触らず、index.html方式や物理ディレクトリ＋index.html方式で段階移行する考え方が分かります。
対象は、既存WordPressサイトを壊さずに、トップや一部固定ページをコード版へ置き換えたいサイト運営者です。
Codexに任せる作業と任せすぎない作業
Codexには、既存ページの構成調査、移行対象ページの整理、静的HTML化の方針、公開前チェック、バックアップとロールバック手順の文書化を任せやすいです。
一方で、WordPress本体の削除、DB操作、.htaccess変更、DNS変更、管理画面設定変更は任せすぎない方が安全です。必要になりそうな場合は停止条件にします。
いきなりWordPressを消さない
既存WordPressサイトには、固定ページ、投稿、画像、フォーム、プラグイン、テーマ設定が関係していることがあります。最初から本体を消すと、戻し方が複雑になります。
実務では、トップだけコード版にする、特定の固定ページだけ物理ディレクトリで置き換える、既存ページを残したまま新しいコード版ページを追加する、という段階移行が扱いやすいです。
index.html方式と物理ディレクトリ方式
index.html方式では、公開ルートや対象ディレクトリにHTMLファイルを置き、静的ページとして表示します。サーバー設定によって優先順位は異なるため、事前に確認します。
物理ディレクトリ＋index.html方式では、たとえばサービス紹介ページを専用ディレクトリで作り、既存WordPressページとは分けて管理できます。戻す時はディレクトリ名を変更するだけで切り離しやすい場合があります。
既存ページを残した段階移行の流れ
- 既存WordPressページのURL一覧を確認する
- コード版にするページを絞る
- プレビュー用の場所でHTML/CSSを作る
- 公開前にtitle、meta、canonical、robotsを確認する
- バックアップを取る
- 問題があればディレクトリをリネームして戻す
- sitemap.xmlとrobots.txtの扱いを確認する
Codexに移行手順を調査させる指示文
目的:
既存WordPressサイトを壊さずにコード版ページへ段階移行する手順を調査する
対象:
トップページ
一部の固定ページ
共通CSS
sitemap.xml
やること:
既存ページ構成を確認する
コード版にする候補を整理する
index.html方式で置き換え可能か確認する
物理ディレクトリ方式の戻しやすさを検討する
本番反映前チェックリストを作る
禁止:
WordPress本体を削除しない
index.phpを変更しない
.htaccessを変更しない
DBを変更しない
既存ページを削除しない
停止:
.htaccess変更が必要そうな場合
DB操作が必要そうな場合
既存URLの挙動が不明な場合本番反映時の禁止事項
Codexに本番反映を頼む場合でも、WordPress本体、index.php、.htaccess、DB、メール設定、DNSには触らないと明記します。コード版ページのアップロードだけに範囲を絞り、上書き前にバックアップを取ります。
問題が出た時は削除ではなく、対象ディレクトリやファイルを退避してから戻す方が安全です。
確認チェックリスト
- 移行対象URLが200 OK
- 既存WordPressページが消えていない
- title、meta description、canonicalが正しい
- robotsがindex,follow
- noindexメタが入っていない
- CSSが読み込まれている
- スマホ表示が崩れていない
- sitemap.xmlに必要なURLが入っている
- 戻し方が報告書に書かれている
失敗しやすい点
移行作業では、トップだけ見て下層の導線やsitemapを見落とすことがあります。また、WordPress側のページとコード版ページでcanonicalがずれると、SEO上の判断がしにくくなります。
Codexには「既存ページを壊していないか」「戻し方があるか」「公開後にどのURLを確認したか」まで報告させます。
コード版へ移す時の受け皿を作る
WordPressからコード版へ移行する時は、静的HTML構成と小規模サイトの作り方をあわせて確認します。
WordPressからCodexコード運用へ移す読み順
WordPressをCodexで更新するだけでなく、固定ページ、LP、SEOサイト、実践ログをファイル管理型のコードサイト運用へ寄せる考え方を整理します。WordPressを完全否定せず、向くケースと段階移行の注意を分けて確認します。
実践ログから分かったこと
CodexでWordPress関連ページを広げる時は、WordPressを否定するよりも、管理画面・DB・プラグインに触れない範囲と、HTML/CSSで安全に増やせる範囲を分けることが重要でした。既存の親ページは壊さず補強し、未作成の子ページだけを追加して、sitemapと公開URLを確認する流れが安全です。
実作業では、ログイン情報、DB情報、wp-config.php、.htaccess、リダイレクト設定、canonical変更は扱わず、ページ群追加、内部リンク、公開前チェックに範囲を絞りました。WordPressからコードサイト運用へ寄せる場合も、いきなり全移行せず、固定ページやLPなど確認しやすい範囲から段階的に進める方が現実的です。
WordPressとCodexのやさしい使い分け
WordPressはブログや管理画面更新に強く、Codexはページ構成、下書き、FAQ、比較表、内部リンク整理に強いです。初心者向けの読み順は WordPressはブログ用？ホームページ用？Codexとの違い で整理しています。
Codex時代のSNS・ブログ・ホームページ戦略へつなぐ
SNS、ブログ、ホームページを別々に考えず、GPTで整理し、Codexでページ・投稿案・導線を作り、人間が確認する流れを Codex時代のSNS・ブログ・ホームページ戦略 で整理しています。
ホームページ / Web制作系の次に読むページ
このページは、2026年5月18日から5月24日のSearch Console反応語に対する既存受け皿として確認しました。新規ページを増やす前に、関連ページへの導線と、このページで受ける検索意図を整理しています。
実践ログから分かったこと
ホームページやWeb制作系の反応語は、単発の作り方だけではなく、HTML/CSS、WordPress、コード運用、公開前チェックまで一続きで受けると分かりやすくなります。既存ページを親ハブとしてつなぎ、検索語ごとの不足ページを後から判断する流れが安全です。