The Complete Hostinger WordPress Troubleshooting Guide

When a WordPress site breaks, the fastest fix is rarely “try everything.” The safer approach is to identify which layer is failing—browser, WordPress, server, CDN, DNS or SSL—and change one variable at a time.

Start with the symptom

First confirm whether the problem affects one page or the whole site, logged-in users or everyone, and one network or every network. Record the exact URL and error before clearing caches or changing plugins.

Changes are not showing

If an edit appears in WordPress but not on the public site, compare a private browser window with the normal browser. Then work outward through page/server cache and CDN cache. A controlled test change is more useful than repeatedly purging every layer.

404 and permalink problems

A 404 after a domain, migration or permalink change usually points to routing rather than missing content. Confirm the domain reaches the intended installation, then resave WordPress permalinks and test a known post URL.

403, 500 and critical errors

These errors need evidence. Note when the error began, check recent theme or plugin changes, and preserve relevant logs. Avoid deleting files or disabling every plugin before you know which change triggered the problem.

Redirect and HTTPS loops

Redirect loops often happen when WordPress, a CDN and server rules disagree about HTTPS or www versus non-www. Choose one canonical address and make each layer agree with it.

Mobile-only problems

If desktop works but mobile does not, test a private window and another device before editing the theme. Mobile browser cache, responsive navigation scripts and CDN variants can create symptoms that do not appear on desktop.

A reliable troubleshooting order

1. Reproduce the issue and save the exact error.
2. Test private browsing and another network/device where relevant.
3. Confirm domain, HTTPS and canonical URL behaviour.
4. Check the smallest relevant cache layer.
5. Review the most recent site change.
6. Use logs and resource data before escalating.

This order protects a working site from unnecessary changes and gives hosting support a reproducible case if escalation is required.