Do you ask for passwords in the form?

No. The public form never requests access. Secure credentials are requested only after the scope and quote are approved.

Who reviews the incident?

The request goes to Jordi Ensenyat, founder of Code Barcelona and a WordPress specialist with more than 15 years of experience.

Is anything changed before the quote?

No. Visible symptoms and scope are reviewed first. Intervention begins after approval and with a rollback path prepared.

Do you work internationally?

Yes. WP Repair handles WordPress and WooCommerce incidents in English and Spanish through a remote service.

WordPress Permalinks Return 404 After a Hosting Change

When the homepage and wp-admin work but posts/pages 404, the new server is usually not routing pretty URLs to index.php. Apache .htaccess, Nginx configuration, document root or subdirectory path may differ from the old host.

Do not change every post slug. The content usually still exists.

Confirm the 404 source

Request a failing permalink and record response headers/body. Compare with a deliberately missing static file and /?p=POST_ID.

Interpret:
/?p=ID works -> WordPress/content okay, rewrite issue
both fail -> URL/database/content/routing broader issue
server-branded 404 -> request never reaches WordPress
theme WordPress 404 -> rewrite reaches application

Test the exact canonical host and HTTPS.

Preserve current rewrite configuration

Back up .htaccess and Nginx/Apache virtual-host configuration where accessible. Record document root and whether WordPress lives in a subdirectory.

Do not paste generic rules over security, language or multisite directives without review.

On managed hosting, obtain the active virtual-host details from cPanel/Plesk/provider.

Regenerate Apache rules

For Apache with mod_rewrite and AllowOverride enabled, visit Settings > Permalinks and Save without changing the structure.

Standard root rules resemble:

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

Use WordPress-generated rules for the installation path; subdirectories/multisite differ.

Configure Nginx explicitly

Nginx ignores .htaccess. The server block normally needs a try_files fallback:

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

Validate and reload Nginx through authorised server/panel controls. Do not add duplicate/conflicting location blocks or expose PHP files.

Managed hosts may require support to change templates.

Check document root and index file

Confirm the domain points to the directory containing this WordPress index.php/wp-config.php. A wrong root can serve a copied homepage/static file while all inner paths fail.

Plesk/cPanel aliases and addon domains can map unexpectedly after migration.

Do not move files until comparing configuration and backups.

Align WordPress URLs and subdirectory

Check home, siteurl, constants and whether core lives under /wordpress while public URLs use /. Preserve the correct front-controller/index arrangement.

Use serialisation-aware migration for old paths/domains. Avoid raw SQL replacement.

For multisite, network paths and rewrite rules require multisite-specific configuration.

Check proxy and cache rules

Cloudflare/host cache may retain 404 responses. Purge affected URLs after origin repair and test after warm-up.

Proxy rules must pass path/query to origin and not strip trailing paths. Compare origin and public response with request IDs.

Do not route all missing static assets through expensive WordPress handling unnecessarily.

Preserve existing redirects and canonical paths

Before replacing rewrite configuration, inventory 301 redirects for old slugs/domains and any trailing-slash/language rules. Reapply them in an order that does not bypass WordPress or create loops.

Test with redirects disabled only on staging. Do not convert every 404 into the homepage; that creates soft-404 SEO problems and hides broken links. Keep one canonical URL per content item.

Handle multisite and language prefixes

Multisite subdirectory/subdomain networks need WordPress-generated network rules, wildcard DNS/SSL where applicable and correct network paths. Multilingual plugins may add /es/ or /ca/ routes before WordPress resolves the post.

Test network admin, each site/language, REST and media separately. Do not use a single-site .htaccess example on multisite; generate/verify rules for the installed network architecture.

Retest mapped domains.

Verify and protect SEO

Test representative posts, pages, categories, feeds, REST, pagination, media and genuine 404s. Confirm canonical URLs and existing redirects.

Monitor 404 logs/Search Console after migration. Recurring care should include a URL crawl before/after hosting changes; permalink repair succeeds when old indexed URLs return the intended content and truly missing paths remain proper 404s.