Post-Migration 404, White Screen, and Missing Images: Symptom-Based Troubleshooting

After migration is complete and DNS resolution has been switched, these three symptoms are the most common. They all look like “migration failed,” but their root causes are completely different. Trying them one by one wastes time—first categorize by symptom, then troubleshoot by category.

Symptom Comparison

The classification criterion is simple: determine whether the issue affects “pages” or “resources.” If pages fail, check the application and configuration; if resources fail, check paths and permissions.

Symptom 1: Homepage Works, Inner Pages Return 404

This is the classic pretty permalink issue. If the homepage loads, it means the Web server and PHP are functioning correctly; the problem lies solely in the URL rewrite rules.

# ① Confirm if rewrite rules exist
grep -A5 'try_files' /etc/nginx/conf.d/example.conf

# ② Standard WordPress rules
cat <<'EOF'
location / {
    try_files $uri $uri/ /index.php?$args;
}
EOF

# ③ Validate and reload after changes
nginx -t && nginx -s reload

# ④ Compare with the old server (most direct: copy the working config)
cat /etc/nginx/conf.d/old.conf

# Apache environment: Check if .htaccess is being ignored
grep -i 'AllowOverride' /etc/httpd/conf/httpd.conf
# It must be set to 'All'; 'None' will cause .htaccess to have no effect

Another possibility: The document root path changed. The old server used /home/wwwroot/site, while the new server is configured with /var/www/html, or there is an extra subdirectory level.

# Confirm root points to the actual file location
grep 'root' /etc/nginx/conf.d/example.conf
ls /var/www/html/index.php

Symptom 2: Whole Site White Screen

A white screen means PHP execution failed, but errors are hidden. The first step is always to enable error display; otherwise, you are just guessing.

# ① Check PHP error logs first (fastest)
tail -50 /var/log/php-fpm/error.log
tail -50 /var/log/php-fpm/www-error.log

# ② Check Web server error logs
tail -50 /var/log/nginx/error.log

# ③ Enable WordPress debugging
wp config set WP_DEBUG true --raw
wp config set WP_DEBUG_LOG true --raw
tail -50 /var/www/html/wp-content/debug.log

# ④ Compare environment differences (most common root cause)
php -v
php -m | tr 'n' ' '          # Extension list, compare with old/new environments
wp core version

Common differences include: mysqli, gd, imagick, curl, mbstring, zip, intl. Missing a single extension can cause fatal errors for corresponding features.

# ⑤ Confirm file ownership (extraction during migration often results in wrong ownership)
ls -l /var/www/html/index.php
ps aux | grep '[n]ginx|[p]hp-fpm' | awk '{print $1}' | sort -u

# Fix ownership
chown -R www:www /var/www/html

Symptom 3: Page Loads, Images Do Not Display

# ① Verify if images actually exist
ls -l /var/www/html/wp-content/uploads/2026/10/ | head

# ② Directory permissions (directories need execute permission x, files need read permission r)
find /var/www/html/wp-content/uploads -type d ! -perm -u+x
find /var/www/html/wp-content/uploads -type f ! -perm -u+r

# Fix permissions
find /var/www/html/wp-content/uploads -type d -exec chmod 755 {} ;
find /var/www/html/wp-content/uploads -type f -exec chmod 644 {} ;

# ③ Directly access an image to see the response
curl -I https://example.com/wp-content/uploads/2026/10/demo.jpg

# ④ Check if domain replacement in the database is complete
wp option get home
wp option get siteurl
mysql -e "SELECT COUNT(*) FROM wp_posts WHERE post_content LIKE '%old_domain%';" dbname

If the response is 403, it is a permission or ownership issue; 404 means the file truly does not exist; 200 but blank page indicates incomplete domain replacement.

Decision Tree

Post-migration anomaly
├─ Homepage works + Inner pages 404
│  ├─ try_files missing      → Add rewrite rules
│  ├─ AllowOverride None     → Change to All (Apache)
│  └─ Incorrect root path    → Verify website document root
├─ Whole site white screen
│  ├─ Check php error log    → Likely missing extension or version incompatibility
│  ├─ Enable WP_DEBUG        → Get specific file and line number
│  ├─ Incorrect file owner   → chown -R
│  └─ Database connection fails → Verify wp-config.php
└─ Page works + Images missing
   ├─ curl returns 403       → Permission/ownership issue
   ├─ Returns 404            → Files not fully transferred
   └─ Returns 200 but blank  → Domain not fully replaced in database

Scenario Walkthrough: Homepage Works, All Inner Pages Are 404

Phenomenon: After moving the website, the homepage opens normally,
but clicking any inner page returns a 404 error, while the backend appears normal.

1. Narrow the scope using “Homepage works” → This indicates the Web service is running, the site root directory is correct, and
   the default document is hit. The issue is limited to “how other paths are handled.”
2. Distinguish between non-existent files and inactive rules → Most modern programs rely on URL rewriting.
   Static files may not actually exist; rules forward requests to the entry file.
3. Check if rewrite rules are loaded → The new environment’s configuration may not include the corresponding rewrite snippet.
   Requests are treated as “looking for static files,” resulting in 404s when not found.
4. Check for missing configuration items or modules → Rules will not work even if written correctly if the corresponding module is missing.
5. Add rules and reload → Add rules that forward requests to the entry file.
6. Save Permalink settings in the backend again → This triggers a rewrite of the rule file
   and confirms directory writability.

# Nginx: Check for forwarding rules to the entry point
nginx -T 2>/dev/null | grep -n 'try_files|rewrite' | head

# Apache: Check if rewrite module is enabled and overrides are allowed
apachectl -M 2>/dev/null | grep rewrite
grep -n 'AllowOverride' /ApacheConfigDir/*.conf | head

# First, compare status codes for homepage vs. inner pages
curl -sS -o /dev/null -w 'home=%{http_code}n' https://example.com/
curl -sS -o /dev/null -w 'post=%{http_code}n' https://example.com/some-known-path/

# Common Nginx syntax
# try_files $uri $uri/ /index.php?$args;

Root Cause: The new environment’s Web configuration lacks URL rewrite rules.
Requests are not forwarded to the program entry point but are treated as static file lookups—thus the homepage (default document) works, but all inner pages return 404.

Two key takeaways:

• “Homepage works + Inner pages 404” almost directly indicates inactive rewrite rules.
  This combination is highly characteristic; there is no need to investigate from directions like root directory permissions or missing files.
• When migrating, move configurations along with files and databases.
  URL rewrite rules are not in the program directory; they belong to Web server configuration and do not sync with file transfers.

8 Common Pitfalls

1. Guessing without checking logs for white screens: Enabling WP_DEBUG and checking PHP error logs provides answers in seconds.
2. Not comparing PHP extensions: Missing a single extension can cause fatal errors.
3. Not fixing ownership after extraction: Extracted migration packages often have root ownership, preventing Web processes from reading them.
4. Forgetting to replicate pretty permalink rules: A working homepage masks this issue.
5. Only replacing home/siteurl: Old domains in post content must also be replaced.
6. Not reloading after changing configuration: nginx -t only validates syntax.
7. Setting upload directory permissions to 777 across the board: Directories should be 755 and files 644; 777 is a security risk.
8. Reconfiguring from memory without comparing old and new environments: Memory-based configuration inevitably leads to omissions.

Real Customer Feedback (From Cloud Market Reviews and Inquiries for Similar Products)

The following excerpts are taken from real buyer reviews and inquiries for similar operations services on Alibaba Cloud / Tencent Cloud / Huawei Cloud Cloud Markets (service providers include our store and peers, provided for reference only, not fictional tickets):

10***02 2024-07-31 5.0 Secure and reliable | Comprehensive features | Affordable price Timely handling, migration successful 10***31 2022-06-22 5.0 Affordable price | Skilled technology | Complete after-sales Good, helped me migrate my years-old site to a new server.

10***31 2022-11-17 5.0 On-time delivery | Timely replies | Affordable price System migration successful 10***31 2022-11-17 5.0 Skilled technology | Secure and reliable | Affordable price Migration successful

1****n Rating: 5.0 points 2018-01-04 18:04