WordPress Site Not Loading After Domain Change? How to Fix Firewall, DNS, SSL, and URL Issues

A WordPress website may stop loading after it is changed from a temporary Hostinger domain to its permanent domain.

For example, the website may have worked correctly on a temporary address, but after pointing the real domain to Hostinger nameservers, it may display a blank page, firewall warning, SSL error, redirect loop, 403 error, or 500 Internal Server Error.

This can lead the site owner to suspect that a WordPress firewall was not disabled before the domain change.

However, changing a domain does not normally require uninstalling a firewall plugin first. The firewall may be involved, especially when Wordfence Extended Protection contains an outdated server path, but several other configuration issues can cause exactly the same symptoms.

This guide explains how to identify the actual cause and recover the website safely.

Quick Answer

Do not immediately delete the firewall.

First, confirm that:

The permanent domain is attached to the correct website in Hostinger.
The domain points to the correct Hostinger nameservers or server IP address.
The DNS change has finished propagating.
A valid SSL certificate has been issued for the new domain.
WordPress uses the new domain in its home and siteurl settings.
No cache or redirect is sending visitors back to the temporary domain.
Wordfence is not loading an invalid wordfence-waf.php file path.

Changing nameservers only controls where DNS requests are sent. It does not always update the website assignment, WordPress database URLs, SSL certificate, firewall configuration, or cached redirects automatically.

Hostinger currently provides a separate Change domain or Connect process for replacing a temporary domain with a permanent domain. Hostinger also notes that a newly connected domain can take up to 24 hours to become fully available.

Identify the Error Before Changing Anything

The message shown in the browser usually indicates which part of the setup is failing.

Error or symptom	Most likely cause
`DNS_PROBE_FINISHED_NXDOMAIN`	Incorrect nameservers, missing DNS records, or propagation
Hostinger default page	Domain is not attached to the intended website
`ERR_SSL_PROTOCOL_ERROR`	SSL certificate is missing, pending, or misconfigured
“Your connection is not private”	Certificate does not include the new domain
Wordfence block page	Wordfence has blocked the IP address or request
`403 Forbidden`	Firewall, ModSecurity, permissions, CDN, or server rule
`500 Internal Server Error`	PHP error, invalid firewall path, or broken server configuration
Redirect to temporary domain	Old WordPress `home` or `siteurl` value
Too many redirects	Conflicting HTTPS, WordPress, hosting, or CDN redirects
Website loads without images or styling	Old domain references or mixed content
Website works through Hostinger preview only	DNS or domain assignment issue

Do not assume the firewall is responsible unless the browser page, PHP error log, or server response contains evidence pointing to it.

Step 1: Create a Backup Before Troubleshooting

Before editing WordPress files or the database, create a complete backup containing:

WordPress files
The database
.htaccess
.user.ini
php.ini, when present
wp-config.php
wordfence-waf.php, when present

In Hostinger, open the website dashboard and check the Backups section.

Download a copy when possible. A backup allows you to restore the site if a database replacement or server configuration change causes a new problem.

Hostinger also recommends backing up both the website files and database before changing a WordPress domain.

Step 2: Confirm That the New Domain Is Attached to the Website

One of the most common mistakes is changing the domain’s nameservers without connecting the domain to the existing website inside Hostinger.

Pointing DNS to Hostinger tells visitors which hosting provider to contact. Hostinger must still know which website directory should answer requests for that domain.

In Hostinger hPanel:

Open Websites.
Find the website using the temporary domain.
Click the three-dot menu.
Look for Change domain or Connect domain.
Select the permanent domain.
Complete all prompts.
Confirm that the new domain appears beside the correct website.

Do not create a second empty WordPress installation unless you actually intend to migrate the website into it.

If the domain is accidentally connected to a new empty website, visitors may see:

A default Hostinger page
A new WordPress installation
A blank directory
A 404 page
The wrong website

Hostinger’s current process for WordPress and other website types requires changing the domain from the website’s menu in hPanel.

Step 3: Verify the Nameservers and DNS Records

Check whether the domain resolves to the correct hosting account.

On Windows, open Command Prompt and run:

nslookup -type=ns example.com
nslookup example.com
nslookup www.example.com

On macOS or Linux, run:

dig example.com NS +short
dig example.com A +short
dig www.example.com A +short

Replace example.com with the real domain.

Check the following:

The nameservers match those assigned by Hostinger.
The root domain resolves to the Hostinger server IP.
The www version resolves correctly.
There is no outdated A record pointing to the previous server.
There is no conflicting AAAA record pointing somewhere else.
DNSSEC is not configured with outdated information from the previous DNS provider.

A conflicting AAAA record can cause a confusing situation where the website works on some networks but fails on others. Some visitors may connect through IPv4 while others attempt to use the incorrect IPv6 address.

Nameserver changes can take from a few minutes to as long as 48 hours to appear consistently across global DNS resolvers, although Hostinger generally advises allowing up to 24 hours for its connection process.

Step 4: Test the Website Before DNS Propagation Finishes

Hostinger provides a preview address that can be used while the domain is connecting.

Open:

Hostinger hPanel > Websites > Website Details

Look for the preview or temporary domain.

If the website loads through the preview address but not through the permanent domain, the WordPress installation is probably still intact. Concentrate on:

DNS propagation
Domain assignment
SSL
CDN configuration
The permanent domain’s DNS records

You can also test the permanent domain against the Hostinger server by temporarily editing your computer’s hosts file.

Example:

192.0.2.10 example.com
192.0.2.10 www.example.com

Replace 192.0.2.10 with the website’s actual Hostinger IP address.

Remember to remove these lines after testing. A hosts-file override affects only your computer and can make you believe DNS has propagated when it has not.

Hostinger officially documents both its preview domain and hosts-file testing methods for websites whose domains are still connecting.

Step 5: Install or Reissue the SSL Certificate

The SSL certificate used by the temporary domain will not automatically secure an unrelated permanent domain.

In Hostinger:

Open Websites.
Select Dashboard beside the website.
Open SSL.
Find the permanent domain.
Install or reinstall the Hostinger SSL certificate.
Wait until its status becomes active.
Enable Force HTTPS only after the certificate is valid.

Also confirm that both versions are covered:

example.com
www.example.com

If the certificate installation fails, check for:

Incorrect nameservers
Conflicting A or AAAA records
Incomplete DNS propagation
The domain being attached to another hosting account
Cloudflare proxying the domain before the origin certificate is ready

Hostinger requires the domain to point correctly to its servers before SSL can be installed successfully. It also advises allowing DNS propagation to complete before retrying a failed certificate installation.

Do not permanently disable HTTPS as the solution. Temporarily unforcing HTTPS can help diagnose an SSL problem, but the correct repair is to install a valid certificate and then restore HTTPS.

Step 6: Determine Whether Wordfence Is Actually Blocking the Site

Wordfence may be responsible when:

The browser displays a Wordfence-branded block page.
The message says that the IP address has been blocked.
The error log mentions wordfence-waf.php.
The website returns a 500 error immediately after its server location changed.
Disabling Wordfence restores the website.

Temporarily deactivate Wordfence through File Manager

When the WordPress dashboard is inaccessible:

Open Hostinger File Manager.
Open the website’s WordPress directory.
Navigate to:

wp-content/plugins/

Rename:

wordfence

to:

wordfence-disabled

Clear the Hostinger cache and any active CDN cache.
Test the website in an incognito window.

Renaming the plugin folder causes WordPress to deactivate Wordfence without deleting its settings or database tables.

Wordfence officially recommends renaming wp-content/plugins/wordfence when a site owner cannot regain access through the dashboard. It also warns that cached block pages may remain visible until caching layers are cleared.

If the website remains unavailable after Wordfence is disabled, the plugin itself is probably not the main cause.

Step 7: Fix a Broken Wordfence Extended Protection Path

This is the firewall-related problem most likely to appear after a website is moved between server directories.

Wordfence Extended Protection loads the firewall before WordPress by using PHP’s auto_prepend_file setting.

The configuration may contain an absolute server path similar to:

/home/oldaccount/domains/temporary-domain/public_html/wordfence-waf.php

After changing the website location or hosting configuration, the correct path may become:

/home/newaccount/domains/example.com/public_html/wordfence-waf.php

If PHP continues trying to load the old location, the website may return:

500 Internal Server Error

The PHP error log may contain:

PHP Fatal error: Unknown: Failed opening required
'/old/path/wordfence-waf.php'

Wordfence confirms that a deleted WAF file or an incorrect absolute file path after a website move can produce this error.

Safest repair when wp-admin is available

Open:

Wordfence > Firewall > All Firewall Options

Under Protection Level, select:

Remove Extended Protection

After the old optimization has been removed:

Confirm that the website works.
Clear all caches.
Return to Wordfence Firewall settings.
Select Optimize the Wordfence Firewall.
Allow Wordfence to generate the correct path for the current server.

Manual repair when wp-admin is unavailable

Back up all configuration files first.

Check these files in the WordPress root:

.htaccess
.user.ini
php.ini

Search for:

Wordfence WAF
auto_prepend_file
wordfence-waf.php

Wordfence normally places its configuration between comments similar to:

# Wordfence WAF
...
# END Wordfence WAF

Remove only the Wordfence WAF block. Do not delete unrelated rewrite, PHP, cache, or security rules.

If php.ini contains a line similar to this:

auto_prepend_file = '/old/path/wordfence-waf.php'

remove the line or remove the corresponding value through the hosting PHP configuration interface.

When .user.ini is involved, allow up to five minutes for the PHP configuration cache to expire. Remove wordfence-waf.php only after the auto_prepend_file configuration has stopped loading it.

These are the manual removal steps currently documented by Wordfence for Extended Protection.

Step 8: Correct the WordPress Home and Site URLs

The WordPress database may still identify the website by its temporary domain.

This can cause:

Redirects to the temporary address
An inaccessible login page
Redirect loops
Broken images
Incorrect canonical URLs
Cookies being set for the wrong domain

The two important WordPress settings are:

home
siteurl

Both should normally use the permanent HTTPS address:

https://example.com

Method 1: Update the URLs in wp-config.php

Open wp-config.php and add the following above the line that says:

/* That's all, stop editing! */

Add:

define( 'WP_HOME', 'https://example.com' );
define( 'WP_SITEURL', 'https://example.com' );

Do not add a trailing slash.

These constants override the database values and can restore access when the dashboard redirects to the old domain. They do not permanently update the database values, so the database should still be corrected later.

Method 2: Update the database through phpMyAdmin

Open the website database and locate the options table.

It is commonly named:

wp_options

However, the prefix may be different.

Find these rows:

home
siteurl

Change both values to:

https://example.com

Alternatively, run:

UPDATE wp_options
SET option_value = 'https://example.com'
WHERE option_name IN ('home', 'siteurl');

Replace wp_options with the actual table name.

Always back up the database before running an SQL query.

Method 3: Use WP-CLI

When SSH and WP-CLI are available:

wp option update home 'https://example.com'
wp option update siteurl 'https://example.com'

WordPress includes these commands in its official migration guidance.

Step 9: Replace the Temporary Domain Throughout the Database

Correcting home and siteurl does not update every old URL.

The temporary domain may still exist in:

Page-builder content
Image URLs
Widgets
Theme settings
Menu items
Plugin settings
Generated CSS files
Canonical URLs
Form redirects
Serialized options

Use a tool that understands serialized WordPress data.

WP-CLI method

Run a dry test first:

wp search-replace \
'https://temporary-domain.hostingersite.com' \
'https://example.com' \
--all-tables-with-prefix \
--skip-columns=guid \
--dry-run

Review the results.

Then run the actual replacement:

wp search-replace \
'https://temporary-domain.hostingersite.com' \
'https://example.com' \
--all-tables-with-prefix \
--skip-columns=guid

Repeat the process for any HTTP version of the old address when necessary:

wp search-replace \
'http://temporary-domain.hostingersite.com' \
'https://example.com' \
--all-tables-with-prefix \
--skip-columns=guid \
--dry-run

WP-CLI’s search-replace command handles PHP serialized data and provides a --dry-run option that reports changes without saving them.

Do not perform a basic text replacement directly inside an exported SQL file unless you understand serialized PHP values. Changing the length of a serialized URL incorrectly can corrupt plugin, widget, or page-builder settings.

Step 10: Clear Every Cache Layer

Old redirects and firewall responses can remain cached after the underlying issue has been repaired.

Clear:

The WordPress caching plugin
Hostinger Cache Manager
LiteSpeed Cache, when active
Redis or object cache
Cloudflare or another CDN
Browser cache
DNS cache

On Windows, clear the local DNS cache with:

ipconfig /flushdns

On Chrome, test the website in an incognito window.

Also check whether the old temporary domain is stored inside:

Redirection plugins
SEO plugins
.htaccess
Cloudflare Redirect Rules
Hostinger redirect settings
Theme code
Custom plugins

WordPress documentation notes that stale cache and incorrect URL settings can make changes appear ineffective even after the underlying files or database have been updated.

Step 11: Regenerate Permalinks and Generated Files

After the site becomes accessible:

Go to Settings > Permalinks.
Do not change the selected structure.
Click Save Changes.

Then regenerate any files created by:

Elementor
Divi
Bricks
WPBakery
Complianz
CSS optimization plugins
Critical CSS services
Image optimization plugins

For Elementor, check:

Elementor > Tools > Regenerate CSS & Data

After regeneration, clear all caches again.

Step 12: Check for Mixed Content and Old Temporary URLs

Open the website and press F12.

Check the Console and Network tabs for requests containing:

temporary-domain.hostingersite.com
http://example.com

Common browser errors include:

Mixed Content
Blocked loading insecure content
net::ERR_CERT_COMMON_NAME_INVALID
403 Forbidden
404 Not Found

When the page uses HTTPS but its CSS, JavaScript, or images still use HTTP or the temporary domain, the design may look broken even though WordPress itself is working.

Correct the URLs in the database, regenerate plugin files, and purge caches rather than manually editing generated CSS files.

For a detailed mixed-content troubleshooting process, add an internal link to:

How to Fix “Blocked Loading Mixed Active Content” Complianz CSS Error in WordPress

Step 13: Re-enable the Firewall Safely

Do not leave the website without firewall protection after testing.

Once the permanent domain works:

Rename wordfence-disabled back to wordfence.
Log in to WordPress.
Reactivate Wordfence if WordPress did not reactivate it automatically.
Open Wordfence > Firewall.
Remove any obsolete optimization.
Optimize the firewall again using the new server path.
Confirm that the firewall shows Enabled and Protecting.
Test the login page, REST API, AJAX, cron, contact forms, and checkout.
Review Wordfence Live Traffic for unintended blocks.

If renaming the folder back immediately locks you out again, use Wordfence Assistant to disable the firewall before restoring the original plugin folder name. Wordfence recommends this process for sites that become blocked again during reactivation.

For related troubleshooting, add an internal link to:

How to Fix Wordfence 403 Loopback Error with Bluehost Cloudflare CDN

What If the Firewall Is Not Wordfence?

The website may use another protection layer, such as:

Hostinger server firewall
ModSecurity
Cloudflare WAF
Sucuri
Solid Security
All-In-One Security
Defender
A hosting CDN
A custom .htaccess deny rule

Check the HTTP status and server logs before disabling protection.

When the response is 403

Review:

Security plugin logs
Cloudflare Security Events
ModSecurity logs
IP allowlists and blocklists
Country-blocking rules
Bot protection
Rate-limiting rules
File and directory permissions

When the response is 500

Review:

Hostinger PHP error logs
WordPress debug.log
.htaccess
.user.ini
php.ini
auto_prepend_file
PHP version compatibility
Fatal plugin or theme errors

When the response is 404

Confirm:

The domain is mapped to the correct document root.
The WordPress files exist in that directory.
The .htaccess file contains normal WordPress rewrite rules.
Permalinks have been regenerated.

Do not create broad firewall bypasses such as allowing every request, disabling all WAF rules permanently, or making sensitive WordPress files publicly accessible.

The goal is to identify and allow the legitimate request, not remove the website’s protection.

Recommended Recovery Order

Use this order to avoid unnecessary changes:

Back up the files and database.
Attach the permanent domain to the correct Hostinger website.
Verify nameservers, A records, AAAA records, and www.
Allow DNS propagation to finish.
Install SSL for the permanent domain.
Test through Hostinger preview or a local hosts-file override.
Identify the exact HTTP response or browser error.
Temporarily disable Wordfence only when firewall involvement is likely.
Repair any outdated auto_prepend_file path.
Correct home and siteurl.
Replace the temporary domain in the database.
Purge every cache.
Regenerate permalinks and generated CSS.
Re-enable and re-optimize the firewall.
Test the complete website.

Final Testing Checklist

Before considering the domain change complete, verify:

The root domain loads through HTTPS.
The www version redirects to the preferred version.
The temporary domain no longer receives public traffic.
/wp-admin/ opens correctly.
Login cookies work on the permanent domain.
Internal pages do not return 404 errors.
Images, CSS, fonts, and JavaScript load.
Forms submit successfully.
Email notifications are delivered.
WooCommerce cart and checkout work, when applicable.
REST API and loopback tests pass.
Scheduled tasks continue running.
Canonical tags use the permanent domain.
The XML sitemap contains the permanent domain.
robots.txt does not block search engines.
Google Search Console has the correct domain property.
Analytics and tag-manager settings use the correct site.
No browser request references the temporary domain.
Wordfence is enabled and optimized using the current path.

Frequently Asked Questions

Do I need to uninstall Wordfence before changing a WordPress domain?

No. A normal domain change does not require Wordfence to be uninstalled.

However, Wordfence Extended Protection may need to be removed and optimized again if the server’s absolute directory path changes. An outdated auto_prepend_file path can cause a 500 error.

Can I bypass the firewall to regain access?

You can temporarily deactivate a WordPress firewall plugin through File Manager for diagnostic purposes. For Wordfence, rename its plugin directory.

Do not create a permanent firewall bypass. Restore protection after identifying and correcting the configuration problem.

Why does my website still redirect to the Hostinger temporary domain?

The temporary address probably remains in the WordPress home or siteurl setting, the database, a redirect rule, or a cache layer.

Correct the two WordPress URL settings, run a serialized-safe database replacement, and clear all caches.

Why does the website work through the Hostinger preview but not the real domain?

This usually indicates a DNS, domain assignment, SSL, or CDN problem rather than missing WordPress files.

Verify that the domain is attached to the intended website and resolves to the correct server.

How long does a Hostinger domain change take?

Hostinger advises that a connected domain may take up to 24 hours to become fully available. Nameserver changes can sometimes take longer to appear consistently across every network and DNS resolver.

Will changing the domain damage my website’s SEO?

It can affect SEO when redirects, canonical URLs, sitemaps, internal links, and Search Console settings are not updated.

When replacing an established public domain, create permanent 301 redirects from every old URL to its corresponding new URL. A temporary development domain that was never indexed should normally be blocked from indexing rather than redirected as a public domain migration.

Conclusion

Forgetting to disable a firewall before connecting a permanent domain does not normally destroy or permanently block a WordPress website.

The most common causes are an incomplete Hostinger domain connection, DNS propagation, missing SSL, incorrect WordPress URLs, cached redirects, or an outdated Wordfence Extended Protection path.

Start by confirming that the permanent domain is attached to the correct website and resolves to the correct server. Then repair SSL and WordPress URL settings. Disable the firewall only as a controlled diagnostic step.

When Wordfence produces a 500 error after a server-path change, remove the old Extended Protection configuration and optimize it again using the website’s current path.

After the website is restored, clear all caches, replace remaining temporary-domain references, regenerate permalinks, and re-enable the firewall so the website remains fully protected.