WordPress Migration and Permalink Guide: From Legacy Sina SAE to Modern Hosting

From a 2011 installation tutorial to a reversible migration manual

The 2011 source depended on a Sina SAE invitation link, a particular console interface, one-click “WordPress for SAE” installation, and proprietary rewrite syntax. This maintained edition provides no registration, promotion, or deployment shortcut. The historical slug remains, but it does not imply that the old procedure still works.

This article was last checked on September 1, 2026. Its goal is to inventory, back up, and move an existing WordPress site from a legacy platform to a verified host, with a controlled cutover and rollback that preserve permalinks. If you do not already have an SAE application, evaluate a target host from its live compatibility, terms, pricing, and support. Do not register for any platform because of this article.

1. Current evidence boundary for Sina SAE

The Sina Cloud SAE product page, login page, and support center were reachable on the audit date. Official PHP runtime documentation also still documents SAE config.yaml, .htaccess, and URL-rewrite behavior.

Those current pages do not, however, verify that the 2011 invitation destination, historical free-service promise, old console buttons, or one-click “WordPress for SAE” catalog item still exist. The runtime documentation also explicitly warns not to combine .htaccess with the handle section of config.yaml in one application. Treat the old tutorial only as history. Existing users should rely on the runtime, service inventory, billing, export capability, and official support answers shown in their own console.

Stop if the existing account cannot be accessed, the database or persistent files cannot be exported, domain control cannot be confirmed, the platform can provide only an incomplete backup, or the target has not passed compatibility tests. Do not delete the old application first, and do not paste the 2011 rewrite fragment into production.

2. Freeze changes and build a complete inventory

Before migration, name the owner, maintenance window, acceptable write freeze, recovery point objective (RPO), and recovery time objective (RTO). Record the DNS provider, TTL, certificates, CDN/proxy, mail, scheduled tasks, object cache, external storage, analytics, and every non-WordPress dependency. Avoid upgrading WordPress, PHP, the database, plugins, and the theme at the same time as the inventory.

Where WP-CLI can be run safely on the existing site, collect a version inventory without credentials:

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

Do not publish the raw output: plugins, paths, hostnames, or errors can disclose attack surface. If the legacy platform has no shell or WP-CLI access, record the same evidence from Tools → Site Health → Info, the platform console, its database manager, and file exports.

Inventory area	Record	Verification question
WordPress	Core release, site/home URLs, permalink structure, multisite state	Are there hard-coded URLs, MU plugins, drop-ins, or custom cron jobs?
PHP	Exact release, SAPI, extensions, php.ini limits, timezone	Do the theme and plugins support the target PHP; are upload, memory, and execution limits sufficient?
Database	MySQL/MariaDB product and release, engines, character sets, collations, prefix, size	Are SQL mode, timezone, packet size, privileges, and index limits compatible?
Files	Core, wp-content, uploads, themes, plugins, configuration, rewrite files	Which paths persist; are there symlinks, external object storage, or generated files?
External systems	DNS, HTTPS, CDN, mail, queues, cache, webhooks, scheduled tasks	Can each be replaced or disabled in staging without messaging real users?

3. Back up the database and files together

The official WordPress backup guide explains that a complete recovery normally requires both database and files. The WXR file from Tools → Export is useful for content portability, but the official export documentation primarily lists posts, pages, comments, fields, taxonomies, menus, and users. It is not a complete disaster-recovery backup of plugin code, themes, configuration, and media binaries.

On a self-managed host with permitted shell access, this is a bounded example. The client configuration must be administrator-readable only, and the backup directory must be outside the Web root. On managed PaaS, use the platform's official database and persistent-storage export paths.

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 is not a universal consistency guarantee for every storage engine and workload; consult MySQL Backup and Recovery for the selected server release. Encrypt backups, restrict reads, set retention, and actually restore the database and files in isolation. Verify checksums, content counts, and sampled media. A “backup succeeded” message without a restore drill is not permission to migrate.

4. Replace “it installs” with target compatibility gates

The live WordPress requirements change; recheck their recommended PHP, MySQL/MariaDB, and HTTPS baseline on execution day. Do not settle for a minimum bootable release. Core, theme, plugins, PHP extensions, database semantics, and runtime behavior must pass as one set.

Gate	Pass	Action on failure
Core and PHP	Target PHP remains supported; staging has no fatal errors, deprecation flood, or checksum anomaly	Replace incompatible extensions/plugins first, or select a supported transitional runtime
Plugins and theme	Source, release, maintenance state, license, and target WordPress/PHP support are verified	Disable and replace unmaintained or unknown components; retain rollback packages
Database	Exact product/release, character set, collation, engine, and SQL mode pass an import test	Correct the conversion plan and re-import; never experiment on the only production database
Files and media	Uploads, derived sizes, permissions, capacity, inodes, and persistence pass sampling	Repair the copy/object-storage adapter and verify again before changing DNS
Platform capability	HTTPS, cron, mail, cache, backup, logs, and recovery access are demonstrated	Pause if any is missing, or document an accepted degradation and compensating control

Prefer separating major changes: complete a reversible move on a substantially equivalent runtime, then upgrade in a separately tested step. For abandoned components, “the page looks normal” does not replace code, security, and write-path verification.

5. Restore and import in isolated staging

Following the WordPress migration handbook, preserve the old database and files before restoring them to staging that receives no real traffic. Protect staging with access control, disable indexing, and disable real mail, webhooks, payments, and analytics. Apply authorization and data-minimization requirements to personal data; staging must not become a public production clone.

A safe order is: create an empty database and least-privilege user; restore files and database; inspect database connections, salts, cache, and environment constants in wp-config.php; repair ownership instead of granting global write access; verify administrator login; then handle URLs. Never put backups, SQL, wp-config.php, logs, or platform keys in Git or the Web root.

If WXR is all you can obtain, import the content with WordPress's importer, but migrate media, themes, plugins, and configuration separately and accept that this is not an isomorphic restore. When media is mapped to SAE Storage, a CDN, or an external service by a plugin, export the original objects, preserve keys and metadata, and validate in batches rather than copying only URLs from HTML.

6. Update site URLs and serialized data safely

After confirming a complete staging backup, inspect home and siteurl separately. The WordPress database can contain PHP-serialized values, so do not use plain SQL text replacement. Official `wp search-replace` handles serialized data and provides --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

Review the dry-run tables and replacement counts before writing. A multisite needs a deliberate assessment of the official --network behavior; do not blindly include tables shared by other applications. Inspect widgets, menus, custom fields, CSS, redirects, canonical links, Open Graph, feeds, and media attachments. Keep a one-to-one map from old URLs to new URLs. Do not rewrite guid without a justified requirement.

7. Permalinks are stable URLs, not a “pseudo-static” sales term

The WordPress permalink documentation defines a permalink as a permanent URL that should remain stable. Choose a simple structure, such as the site's established /%postname%/ or historical /html/%post_id%.html. Migration alone is not a reason to change it.

If a change is unavoidable, first export every published post, page, category, tag, pagination, feed, and attachment URL. Build explicit per-URL or pattern-based 301/308 mappings and test collisions and redirect chains in staging. Do not redirect every old URL to the home page or turn real 404s into 200s. WordPress's internal rewrite rules and the Web server route must agree.

8. Routing boundaries for Apache, Nginx, and Caddy

These are minimal routing examples for a site at the Web root, not complete virtual hosts to paste into every server. Use only the Web server actually deployed, back up its configuration, and run its syntax test first. Verify paths, the PHP-FPM socket, permissions, and reverse-proxy headers against the real environment.

This Apache root .htaccess example depends on mod_rewrite and requires the relevant override to be permitted by an administrator; see 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>

In the correct Nginx server block, use `try_files` to pass nonexistent paths to WordPress. The PHP location and FastCGI security parameters must still be configured correctly:

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

Caddy's `php_fastcgi` includes front-controller try-files behavior and normally pairs with root and file_server:

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

Replace the example domain, root, and socket with verified values. Validate with apachectl configtest, nginx -t, or caddy validate --config /path/to/Caddyfile, then reload gracefully. If an existing SAE application still uses platform config.yaml, follow only its current runtime documentation and do not combine its rewrite with .htaccess.

9. HTTPS, DNS, and the cutover window

Before migration, prove access to the registrar and DNS account and record every DNS value and TTL. Reduce TTL at least one old-TTL interval before the planned switch. Complete the certificate, SNI, full chain, single-hop HTTP-to-HTTPS redirect, and WordPress URL tests on the target first. Do not change nameservers or remove the old certificate before the target is ready.

Test the new origin using a local hosts override, a controlled temporary domain, or a proxy feature that can select an origin without public exposure. At cutover, freeze writes or implement an explicit incremental-sync design; record the final database snapshot and checkpoint, then change DNS. Keep the old environment read-only and recoverable until TTL, monitoring, logs, login, publishing, media, and background jobs are stable. Purge CDN/proxy caches only within an audited scope; a global purge must not hide an origin error.

10. Test write paths, not only the home page

Replace the sample paths with known, non-private staging content before running this check:

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 tests should cover the home page, permalink, category/tag, search, pagination, feed, REST API, login/logout, draft creation/update, upload, and thumbnail generation. Check form nonces, roles, comments policy, cache invalidation, cron, mail sandbox, 404s, canonical links, and old-URL redirects. Compare pre/post counts for posts, pages, comments, and users; validate key tables, sampled media, and error logs. A performance result needs a documented method and data size, not an impression.

11. Rollback is more than “change DNS back”

Trigger	Immediate action	Recovery evidence
Widespread 5xx or rewrite loop	Stop new-site writes and restore the previous server configuration	Configuration syntax passes; permanent URLs, static files, and 404 behavior recover
Login, publish, or media write fails	Keep maintenance mode and inspect PHP, permissions, sessions, database, and persistent storage	Administrator action and a new media item succeed in isolation
Missing or misencoded data	Stop writes on both sides and restore the last consistent snapshot	Counts, checksums, character samples, and attachment relationships agree
Cutover must return to old host	Record the new-site change boundary, restore old database/files, and switch DNS	No split-brain; monitoring and logs normalize after TTL

The rollback plan must name the decision maker, threshold, backup ID, recovery commands, DNS values, write freeze, and communication path. If comments, orders, users, or content were created after cutover, never overwrite them blindly; stop writes and design a data merge. Retain a read-only log and timeline of the failed environment while removing credentials and personal data.

12. Delivery checklist

• [ ] Legacy applications, databases, persistent files, external services, billing, and domain control are inventoried.
• [ ] Database, complete files, and WXR content export are stored and verified in protected locations.
• [ ] At least one isolated restore succeeded, with matching content counts, key tables, and sampled media.
• [ ] Target WordPress, PHP, MySQL/MariaDB, plugin, theme, and extension compatibility is demonstrated.
• [ ] Staging is not indexed, sends no real mail/webhooks/payments, and exposes no personal data publicly.
• [ ] URL replacement ran as a dry run first, preserves serialized data, and does not rewrite guid without reason.
• [ ] Exactly one Web-server rewrite path is enabled after syntax validation.
• [ ] HTTPS, DNS, TTL, canonical, redirect, and CDN-cache behavior were rehearsed.
• [ ] Read/write, authorization, media, cron, mail sandbox, REST, feed, 404, and log tests pass.
• [ ] Rollback triggers, write freeze, backup ID, owner, and data-merge boundary are recorded.
• [ ] The legacy application remains until acceptance and retention end; deletion requires separate approval and a final backup.
• [ ] There is no invitation, affiliate, promotion, legacy download, or unverified platform promise.

13. Current official references

• Sina Cloud: SAE
• Sina Cloud: login
• Sina Cloud: support center
• Sina Cloud: SAE PHP runtime
• WordPress: requirements
• WordPress: backups
• WordPress: Tools → Export
• WordPress: migrating
• WordPress: permalinks
• WP-CLI: search-replace
• WP-CLI: rewrite flush
• MySQL: Backup and Recovery
• Apache HTTP Server: mod_rewrite
• Nginx: try_files
• Caddy: php_fastcgi

14. Safe archive of the 2011 source

The complete visible source_export body follows with trailing whitespace normalized and exactly 13 historical destinations narrowly replaced: 1 Sina SAE invitation/referral destination, 11 dead legacy-site image destinations, and 1 dead demonstration-site destination. Visible link labels and all other historical text are preserved. The unmodified export and Git history retain the original values.

Warning: the archived free-service promise, registration/install procedure, console labels, password prompt, rewrite configuration, and demonstration address are 2011 historical content, not current facts or operating advice. Every link is inside the outer code fence and must not be used as a registration, download, configuration, or deployment entry point.

在新浪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]) 。