WordPress 移行・パーマリンクガイド：旧 Sina SAE から現行ホスティングへ

Table of Contents

2011 年のインストール記事から、戻せる移行手順書へ

2011 年の原文は、Sina SAE の招待リンク、特定の管理画面、「WordPress for SAE」のワンクリック導入、独自の rewrite 構文に依存していました。この保守版は登録、宣伝、配備の近道を提供しません。歴史的 slug は維持しますが、旧手順が今も機能するという意味ではありません。

この記事の最終確認日は 2026 年 9 月 1 日です。既存の WordPress サイトを旧プラットフォームから検証済みホストへ移すため、完全な棚卸し、バックアップ、パーマリンクを守る切り替えとロールバックを説明します。既存の SAE アプリがない場合は、候補ホストの現在の互換性、規約、価格、サポートから評価してください。この記事を理由にプラットフォームへ登録してはいけません。

1. Sina SAE の現在の証拠境界

Sina Cloud SAE 製品ページ、ログインページ、サポートセンターは監査日にアクセスできました。公式の PHP ランタイム文書にも、SAE の config.yaml、.htaccess、URL rewrite の動作が記載されています。

ただし、これらの現在のページは、2011 年の招待先、当時の無料提供の約束、旧管理画面のボタン、「WordPress for SAE」のワンクリック項目が現在も存在することを確認していません。ランタイム文書は、同じアプリで .htaccess と config.yaml の handle 節を併用しないよう明確に警告しています。旧記事は歴史資料としてのみ扱い、既存利用者は自分の管理画面に表示されるランタイム、サービス、請求、エクスポート機能、公式サポート回答を基準にしてください。

既存アカウントへログインできない、データベースや永続ファイルを出力できない、ドメイン管理権を確認できない、プラットフォームが不完全なバックアップしか提供しない、または移行先が互換性試験を通っていない場合は停止します。旧アプリを先に削除したり、2011 年の rewrite 断片を本番へ貼り付けたりしてはいけません。

2. 変更を凍結し、完全な棚卸しを作る

移行前に責任者、保守時間帯、許容する書き込み停止時間、目標復旧時点（RPO）、目標復旧時間（RTO）を決めます。DNS 事業者、TTL、証明書、CDN／proxy、メール、定期処理、object cache、外部 storage、analytics、WordPress 外の依存関係を記録します。棚卸しと同時に WordPress、PHP、データベース、plugin、theme を一斉更新しないでください。

既存サイトで WP-CLI を安全に実行できる場合は、認証情報を含まないバージョン台帳を採取できます。

set -euo pipefail

wp core version
wp core verify-checksums
wp option get home
wp option get siteurl
wp option get permalink_structure
wp plugin list --fields=name,status,version,update --format=json
wp theme list --fields=name,status,version,update --format=json
php -v
php -m | LC_ALL=C sort
mysql --version

出力をそのまま公開しないでください。Plugin、path、hostname、error は攻撃面を漏らす場合があります。旧プラットフォームで shell／WP-CLI を使えない場合は、「ツール → サイトヘルス → 情報」、管理画面、データベース管理画面、ファイル出力から同じ証拠を記録します。

棚卸し領域	必須記録	確認事項
WordPress	Core 版、site／home URL、パーマリンク、multisite 状態	Hard-coded URL、MU plugin、drop-in、独自 cron があるか
PHP	正確な版、SAPI、extension、`php.ini` 制限、timezone	Theme／plugin が移行先 PHP を支援し、upload／memory／実行時間が十分か
データベース	MySQL／MariaDB 製品と版、engine、文字集合、collation、prefix、容量	SQL mode、timezone、最大 packet、権限、index 制限が互換か
ファイル	Core、`wp-content`、uploads、theme、plugin、設定、rewrite file	永続化 path、symbolic link、外部 object storage、生成物があるか
外部システム	DNS、HTTPS、CDN、mail、queue、cache、webhook、定期処理	Staging で代替／無効化でき、実利用者へ通知しないか

3. データベースとファイルを一緒にバックアップする

WordPress 公式バックアップガイドは、完全復旧には通常データベースとファイルの両方が必要だと説明しています。「ツール → エクスポート」の WXR は内容の移送に有用ですが、公式エクスポート文書が主に列挙するのは記事、ページ、コメント、フィールド、分類、メニュー、利用者です。Plugin code、theme、設定、media binary を含む完全な災害復旧用バックアップではありません。

Shell が許可された自己管理ホストでは、次の限定的な例を使えます。Client 設定は管理者だけが読み、backup directory は Web root の外へ置いてください。管理 PaaS では公式の database／persistent storage export を使います。

set -euo pipefail
umask 077

BACKUP_DIR='/absolute/path/outside-web-root/wordpress-migration'
WORDPRESS_ROOT='/srv/wordpress'
MYSQL_CLIENT_CONFIG='/absolute/path/to/protected-client.cnf'
DATABASE_NAME='wordpress'

install -d -m 0700 "$BACKUP_DIR"
test -r "$MYSQL_CLIENT_CONFIG"
mysqldump --defaults-extra-file="$MYSQL_CLIENT_CONFIG" --single-transaction --routines --triggers "$DATABASE_NAME" > "$BACKUP_DIR/database.sql"
tar -C "$WORDPRESS_ROOT" -czf "$BACKUP_DIR/files.tar.gz" .
sha256sum "$BACKUP_DIR/database.sql" "$BACKUP_DIR/files.tar.gz" > "$BACKUP_DIR/SHA256SUMS"

--single-transaction は、すべての storage engine／workload に対する万能な整合性保証ではありません。選択したサーバー版の MySQL Backup and Recoveryを確認してください。Backup を暗号化し、読み取りを制限し、保持期間を設定し、database と file を隔離環境で実際に復元します。Checksum、content 件数、media sample を検証してください。復元訓練のない「backup 成功」表示は移行許可になりません。

4. 「インストールできる」を移行先の互換性門番に置き換える

WordPress の現在の動作要件は更新されます。実行日に推奨 PHP、MySQL／MariaDB、HTTPS 基準を再確認してください。起動できる最低版だけで済ませず、core、theme、plugin、PHP extension、database 意味論、runtime behavior を一組として検証します。

門番	合格	失敗時の動作
Core と PHP	移行先 PHP が支援期間中で、staging に fatal error、deprecation 洪水、checksum 異常がない	非互換 extension／plugin を先に交換するか、支援中の移行用 runtime を選ぶ
Plugin と theme	入手元、版、保守状況、license、対象 WordPress／PHP 支援を確認	放置または動作不明の部品を無効化／交換し、rollback package を保持
データベース	正確な製品／版、文字集合、collation、engine、SQL mode が import test を通る	変換計画を直して再 import し、唯一の本番 DB で試さない
ファイルと media	Upload、派生 size、権限、容量、inode、永続化を抽出検査	Copy／object-storage adapter を直して再検証し、先に DNS を変えない
Platform 能力	HTTPS、cron、mail、cache、backup、log、復旧 access を実証	一つでも欠ければ停止し、または降格と補償統制を文書で承認

大きな変更は分離します。まず極力同等の runtime へ戻せる移行を完了し、その後に別工程で upgrade と test を行います。保守停止部品では「見た目が正常」を code、security、書き込み経路の確認代わりにしないでください。

5. 隔離 staging で復元・import する

WordPress 移行手引きに従い、旧 database／file を保存してから実 traffic を受けない staging へ復元します。Staging は access control で保護し、indexing、実 mail、webhook、payment、analytics を無効化します。個人データには権限と最小化要件を適用し、staging を公開された本番 clone にしてはいけません。

安全な順序は、空 database と最小権限 user の作成、file／database の復元、wp-config.php の database 接続・salt・cache・環境定数の確認、全体書き込み権限ではなく ownership の修復、管理者 login の検証、最後に URL 処理です。Backup、SQL、wp-config.php、log、platform key を Git や Web root に入れてはいけません。

WXR しか取得できない場合は WordPress importer で内容を復元しますが、media、theme、plugin、設定を別途移行し、同型の完全復元ではないと認識します。Media が SAE Storage、CDN、外部 service へ plugin で map される場合は、元 object、object key、metadata を保存して batch ごとに検証し、HTML 内 URL だけをコピーしないでください。

6. Site URL と serialized data を安全に更新する

Staging の完全 backup を確認後、home と siteurl を別々に調べます。WordPress database には PHP serialized value があり得るため、単純な SQL 文字列置換を使わないでください。公式 `wp search-replace`は serialized data を扱い、--dry-run を提供します。

set -euo pipefail

OLD_URL='http://legacy.example'
NEW_URL='https://www.example.com'

wp search-replace "$OLD_URL" "$NEW_URL" --all-tables-with-prefix --skip-columns=guid --dry-run

 # Review the dry-run report and backup checkpoint before this write.
wp search-replace "$OLD_URL" "$NEW_URL" --all-tables-with-prefix --skip-columns=guid
wp rewrite flush

書き込み前に dry-run の table と置換件数を審査します。Multisite では公式 --network の動作を個別に評価し、他 application と共有する table まで無条件に含めません。Widget、menu、custom field、CSS、redirect、canonical、Open Graph、feed、media attachment を確認し、旧 URL と新 URL の一対一 mapping を保存します。理由なく guid を書き換えないでください。

7. パーマリンクは安定 URL であり、「疑似静的化」という宣伝語ではない

WordPress パーマリンク文書は permalink を、安定しているべき永久 URL と定義します。既存公開サイトで使っている /%postname%/ や歴史的な /html/%post_id%.html など、簡潔な構造を選びます。移行そのものは構造変更の理由になりません。

変更が不可避なら、全公開記事、page、category、tag、pagination、feed、attachment URL を先に export します。明確な URL ごと、または pattern 別の 301／308 mapping を作り、staging で衝突と redirect chain を検査します。全旧 URL を home へ転送したり、実際の 404 を 200 に見せたりしてはいけません。WordPress 内部 rewrite と Web server route を一致させます。

8. Apache、Nginx、Caddy の routing 境界

以下は site が Web root にある場合の最小 routing 例で、全 host へ貼れる完全な virtual host ではありません。実際に配備する一種類の Web server だけを選び、設定を backup して syntax test を先に実行します。Path、PHP-FPM socket、権限、reverse-proxy header は現場で確認してください。

Apache root の .htaccess 例は mod_rewrite に依存し、管理者が関連 override を許可する必要があります。Apache mod_rewriteを参照してください。

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index[.]php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

Nginx の正しい server block で `try_files`を使い、存在しない path を WordPress へ渡します。PHP location と FastCGI security parameter は別途正しく設定する必要があります。

location / {
    try_files $uri $uri/ /index.php?$args;
}

Caddy の `php_fastcgi`には front controller 用 try-files 動作があり、通常 root、file_server と組み合わせます。

example.com {
    root * /srv/wordpress
    encode zstd gzip
    php_fastcgi unix//run/php/php8.3-fpm.sock
    file_server
}

例の domain、root、socket を検証済みの値に変えます。apachectl configtest、nginx -t、caddy validate --config /path/to/Caddyfile で検証後、graceful reload します。既存 SAE app が platform config.yaml を使う場合は現在の公式 runtime 文書だけに従い、.htaccess rewrite と併用しないでください。

9. HTTPS、DNS、切り替え時間帯

移行前に registrar／DNS account への access を実証し、全 record と TTL を保存します。予定切り替えの少なくとも旧 TTL 一回分前に TTL を下げます。移行先で certificate、SNI、full chain、HTTP から HTTPS への一段 redirect、WordPress URL test を先に完了してください。移行先準備前に nameserver を変えたり旧 certificate を消したりしません。

Local hosts override、管理下の一時 domain、または公開せず origin を選べる proxy 機能で新 origin を試します。切り替え時には書き込みを凍結するか、明確な増分同期を設計し、最終 database snapshot／checkpoint を記録してから DNS を変更します。TTL、monitoring、log、login、publish、media、background job が安定するまで旧環境を read-only かつ復旧可能にします。CDN／proxy cache は監査済み範囲だけ purge し、全消去で origin error を隠さないでください。

10. Home page だけでなく書き込み経路をテストする

実行前に sample path を staging に実在する非私密 content／media に変えます。

set -euo pipefail

BASE_URL='https://www.example.com'
SAMPLE_POST_PATH='/known-published-post/'
SAMPLE_MEDIA_PATH='/wp-content/uploads/2026/01/known-image.jpg'

for path in / "$SAMPLE_POST_PATH" "$SAMPLE_MEDIA_PATH" /wp-login.php /wp-json/; do
  curl --fail --silent --show-error --location --output /dev/null "${BASE_URL}${path}"
done

curl --silent --show-error --head "$BASE_URL/" |
  sed -n -e '/^HTTP[/]/p' -e '/^location:/Ip' -e '/^strict-transport-security:/Ip'

Browser test は home、permalink、category／tag、search、pagination、feed、REST API、login／logout、draft 作成／更新、upload、thumbnail 生成を含めます。Form nonce、role、comment policy、cache invalidation、cron、mail sandbox、404、canonical、旧 URL redirect を確認します。移行前後の記事／page／comment／user 件数、主要 table、media sample、error log を比較します。性能結果には方法とデータ量が必要で、感覚だけでは不十分です。

11. Rollback は「DNS を戻す」だけではない

Trigger	即時動作	復旧証拠
広範な 5xx／rewrite loop	新 site 書き込みを止め、直前の server 設定を復元	設定 syntax 合格；永久 URL、static file、404 が復旧
Login、publish、media write 失敗	Maintenance mode を保ち、PHP、権限、session、database、persistent storage を確認	管理者操作と新 media が隔離 test で成功
Data 欠落／encoding 破損	両側書き込みを止め、最後の一貫 snapshot を復元	件数、checksum、文字 sample、attachment 関係が一致
旧 host へ退避が必要	新 site 変更境界を記録し、旧 database／file と DNS を復元	Split-brain がなく、TTL 後に monitoring／log が正常

Rollback 計画には決定者、threshold、backup ID、復旧 command、DNS 値、書き込み凍結、連絡経路を明記します。切り替え後に comment、order、user、content が生じた場合は無条件に上書きせず、書き込みを止めて data merge を設計します。失敗環境の read-only log／timeline は残し、認証情報と個人データを除去します。

12. 引き渡しチェックリスト

[ ] 旧 platform の app、database、persistent file、外部 service、billing、domain 管理権を棚卸しした。
[ ] Database、完全 file、WXR content export を保護場所へ保存し検証した。
[ ] 一回以上の隔離復元が成功し、content 件数、主要 table、media sample が一致した。
[ ] 移行先 WordPress、PHP、MySQL／MariaDB、plugin、theme、extension の互換性を実証した。
[ ] Staging は index されず、実 mail／webhook／payment を送らず、個人データを公開しない。
[ ] URL 置換を先に dry-run し、serialized data を保護し、理由なく guid を変更しない。
[ ] Syntax 検証後、一種類だけの Web server rewrite 経路を有効にした。
[ ] HTTPS、DNS、TTL、canonical、redirect、CDN cache 動作を演習した。
[ ] Read/write、認可、media、cron、mail sandbox、REST、feed、404、log test が通る。
[ ] Rollback trigger、書き込み凍結、backup ID、責任者、data-merge 境界を記録した。
[ ] 受入・保持期間終了まで旧 app を削除しない。削除には別承認と最終 backup が必要。
[ ] 招待、affiliate、宣伝、旧 download、未検証 platform 約束がない。

13. 現在の公式資料

14. 2011 年原文の安全なアーカイブ

以下は source_export の可視本文を完全に保存し、行末空白だけを正規化して、歴史的な 13 個の宛先だけを限定的に置換しています。内訳は Sina SAE の招待／紹介先 1 件、停止した旧サイトの画像先 11 件、停止した実演サイト先 1 件です。表示されるリンク文字と他の歴史本文は保持しています。未変更の export／Git 履歴には元の値が残ります。

警告：アーカイブ内の無料提供の約束、登録／導入手順、管理画面名、パスワード指示、rewrite 設定、実演アドレスは 2011 年の歴史資料であり、現在の事実や操作助言ではありません。すべてのリンクは外側の code fence 内にあり、登録、download、設定、配備の入口として使用してはいけません。

在新浪SAE上安装wordpress并实现伪静态


核心提示：新浪SAE是Sina App Engine的简称，它是新浪免费提供的应用开发和运行平台，我们已经在前面介绍过。今天向大家介绍，如何在新浪SAE上建立自己的wordpress博客，并实现伪静态。

新浪SAE是Sina App Engine的简称，它是新浪免费提供的应用开发和运行平台，我们已经在前面介绍过。今天向大家介绍，如何在新浪SAE上建立自己的wordpress博客，并实现伪静态。

**1、注册帐号：**要使用新浪SAE搭建自己的博客，当然首先需要注册一个新浪SAE的帐号。注册地址：[http://sae.sina.com.cn/]([historical invitation/referral target redacted] )，现在已经可以和自己的新浪微薄进行绑定注册了。

![]([historical dead image target redacted])

**2、创建应用：**注册登录后，点击“我的应用”，能够显示出已经创建的应用列表。点击下面的创建新应用，进入应用设置。

![]([historical dead image target redacted])

**3、创建二级域名：**这里设置的就是我们所创建的应用的访问地址，设置好后直接点击创建应用，这个一个应用就创建完成了。

![]([historical dead image target redacted])

**4、安装wordpress博客程序：**创建应用后直接点击“推荐应用”，选择Wordpress for sae后面的安装，进入选择应用界面，这里为了安全，需要你输入注册时填写的安全验证密码。

![]([historical dead image target redacted])

这里，在第一项里选择我们刚刚建立的应用名称，第二项选择“安装为新版本”，第三项随便填入一个1-9的整数，然后点下面的“安装到以上位置”。

![]([historical dead image target redacted])

到这里系统会自动加载选择的应用程序，加载完成后会显示如下界面，点击“点击此处进入初始化页面点此管理该应用”进入博客的设置。

![]([historical dead image target redacted])

**5、设置wordpress。**也就是咱们最常见的设置，依次在下面输入你的站点标题、用户名、密码，点击确认，到这里，你的博客就已经建好了。访问地址就是你创建的应用地址。

![]([historical dead image target redacted])

**6、实现wordpress的伪静态：**伪静态的好处大家都清楚，但是常用的伪静态方法对SAE来说并不适用，SAE有自己的伪静态设置方法。首先从“应用列表”进入我们刚刚建立的应用。点击“应用管理”中的“代码管理”。

![]([historical dead image target redacted])

选择“操作”中的“编辑代码”

![]([historical dead image target redacted])

进入新的页面后，我们会看到，左上角有一个“Config Path”，SAE就是通过设置它来实现伪静态的。点击它，在右侧会显示它的编辑页面，在里面加入如下代码。

> handle:

> – rewrite: if(!is_dir() && !is_file()) goto “index.php?%{QUERY_STRING}”

如下图：

![]([historical dead image target redacted])

点击SAVE保存。

最后将wordpress里的固定链接格式设置成如下格式“/html/%post_id%.html”，这个可以根据个人喜好进行调整。

![]([historical dead image target redacted])

至此，wordpress的伪静态就设置完成了。

最后给大家一个演示，属于本站的一个备份，[http://earnfs.sinaapp.com/]([historical dead demo target redacted]) 。