The Website Bugs We Fix Most Often (and How to Catch Them Early)

Most of the broken websites that reach us are not broken in interesting ways. They fail in the same dozen places, often because of a hosting default nobody changed or a detail that only shows up with real users. Here are the ones we fix most often, roughly in order of how much business they quietly cost.

1. The contact form "works" but emails never arrive

The form shows a thank-you message, so everyone assumes it works. Meanwhile the emails are going to spam or being rejected outright, because the site sends mail through the server's mail() function from an address like noreply@yourdomain.com with no proof it is allowed to. Gmail and Outlook now reject or bin most unauthenticated mail.

• Send through a real mail service over SMTP or an API, not PHP's mail().
• Publish SPF, DKIM and DMARC records for the sending domain.
• Store every submission in the database as well, so a mail failure never loses a lead.
• Test monthly by submitting the form yourself and checking it arrives in the inbox, not just that the page said thank you.

2. Nepali text shows as ???? or broken characters

Devanagari and emoji need a full Unicode encoding end to end. In MySQL the old utf8 character set only stores up to three bytes per character, so emoji and some characters fail; the correct choice is utf8mb4. Every layer has to agree: the database, the tables and columns, the connection, and the HTML.

-- database and table
ALTER DATABASE site CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
ALTER TABLE posts CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

// PHP connection
$pdo = new PDO('mysql:host=localhost;dbname=site;charset=utf8mb4', $user, $pass);

<!-- HTML -->
<meta charset="utf-8">

If the data is already stored wrongly, converting the table is not enough: it was double-encoded on the way in and needs repairing. Take a backup before you try.

3. Times are off by 15 minutes, or by 5 hours 45

Nepal is UTC+05:45, one of the few time zones not on a whole or half hour, and it exposes every time zone shortcut. Typical symptoms are bookings showing the wrong slot, reports grouping sales into the wrong day around midnight, and cron jobs firing at odd times. The usual cause is that PHP, MySQL and the server each assume a different zone.

• Store times in UTC in the database and convert only when displaying.
• Set the zone explicitly, for example date_default_timezone_set('Asia/Kathmandu') in PHP, instead of relying on the server default.
• Never hard-code an offset like +5.5 or +6. Use a named zone so the conversion is always correct.

4. "Headers already sent" and the white screen

In PHP, redirects and cookies must be sent before any output. A single space or blank line before <?php, or after a closing ?> in an included file, counts as output and breaks every redirect after it. So does a byte-order mark added by some editors. The fix is to remove the stray output and to leave out the closing ?> in files that contain only PHP. A completely white page is usually a fatal error with error display turned off: check the error log rather than guessing.

5. Updates do not show up

You change the price, the site still shows the old one, but only for some people. Something between the code and the visitor is serving a cached copy: a page cache plugin, a CDN, the browser holding an old CSS file, or PHP's OPcache running old code after files were replaced. Fix the process, not just the instance: version your CSS and JavaScript file names so a change creates a new URL, purge the page cache and CDN as part of every deploy, and reset OPcache when you release.

6. Uploads fail without a clear message

Shared hosting often limits uploads to 2 MB by default, and phones take photos far larger than that. The upload silently fails or the form returns empty. Raise upload_max_filesize and post_max_size to sensible values, check the web server's own body size limit as well, show a clear error when a file is too large, and resize images on upload so the site does not store 8 MB photos.

7. Mixed content after moving to HTTPS

The padlock disappears or images do not load because pages still reference http:// URLs, often hard-coded in old posts or the database. Search and replace the old URLs carefully (on WordPress, with a tool that handles serialised data), redirect all HTTP traffic to HTTPS, and add a Content-Security-Policy: upgrade-insecure-requests header as a safety net.

8. Logins that randomly sign people out

Sessions vanish when the site is reachable at both www and the bare domain, because the cookie is set for one and the visitor lands on the other. Other causes are a shared host cleaning the session folder aggressively, or cookies missing the Secure and SameSite attributes that browsers now expect. Pick one canonical domain and redirect the other to it, and set session cookie options explicitly.

9. Scheduled jobs that stopped months ago

Invoice reminders, backups, sitemap updates: they ran at launch and nobody noticed when they stopped. WordPress's built-in scheduler only runs when someone visits the site, and server cron jobs fail quietly when a path changes or the CLI PHP version differs from the web one. Make every scheduled job record when it last succeeded, and alert someone when it has not run on time.

The expensive bugs are not the ones that crash the site. They are the ones that look fine while quietly losing leads.

How to catch these before your customers do

• Keep error logging on in production, with display off, and actually read the log weekly.
• Add uptime monitoring that checks a real page and the contact form, not just that the server answers.
• Keep a short manual test list for every release: submit the form, log in, buy something, upload a photo, view on a phone.
• Keep PHP and plugins current; old versions cause several of the bugs above. Our guide to upgrading an old PHP website covers how.
• Run a technical SEO audit after any big change, since broken redirects and mixed content hurt rankings too.

Most of these fixes are an afternoon each once someone has found the cause. Finding the cause is the hard part, and it is what a good maintenance routine is for. If your site has one of these problems, or a stranger one, our web development team can diagnose it and tell you what the fix involves before any work starts.