Whether you are a developer debugging a client project or a business owner trying to understand why your site is not working, these website problems and solutions will save you hours of frustration. We have fixed every single one of these for clients at Arsyk Media, and they come up far more often than you would expect.

1. 404 Not Found

What it looks like

Your visitor clicks a link and sees a blank page or a generic "404 - Page Not Found" message. In the browser console, you will see a GET /some-page.html 404 (Not Found) error.

Why it happens

The URL points to a file or route that does not exist on the server. The most common causes are a typo in the file path, a page that was renamed or deleted without updating the links that point to it, or a case sensitivity mismatch. On Linux servers, About.html and about.html are two different files.

The fix

First, check the actual file path on your server. Make sure the file exists exactly where the URL expects it. If you renamed a page, set up a redirect from the old URL to the new one. In an .htaccess file:

Redirect 301 /old-page.html /new-page.html

For a site with many pages, create a custom 404 page that helps visitors find what they need instead of hitting a dead end. Also run a broken link checker periodically. Free tools like Screaming Frog will crawl your site and flag every 404.

2. 500 Internal Server Error

What it looks like

The page fails to load entirely and displays "500 Internal Server Error." No useful information is shown to the visitor.

Why it happens

This is a catch-all server-side error. The most frequent culprits are a syntax error in your .htaccess file, a misconfigured server setting, a PHP script crashing, or a permissions issue on the server. On shared hosting, exceeding your memory limit will also trigger a 500.

The fix

Check your server error logs first. On Apache, look at /var/log/apache2/error.log. On shared hosting, check the error log in your cPanel. If you recently edited .htaccess, rename it temporarily to see if the error disappears. A common mistake is an invalid rewrite rule:

# This will cause a 500 if mod_rewrite is not enabled
RewriteEngine On
RewriteRule ^old-path$ /new-path [R=301,L]

# Fix: Wrap it in an IfModule check
<IfModule mod_rewrite.c>
  RewriteEngine On
  RewriteRule ^old-path$ /new-path [R=301,L]
</IfModule>

If the issue is a PHP error, enable error reporting temporarily in your script to see the actual message: ini_set('display_errors', 1);. Fix the error, then turn display_errors back off in production.

3. Mixed Content Warning (HTTP/HTTPS)

What it looks like

Your browser console shows warnings like Mixed Content: The page was loaded over HTTPS, but requested an insecure resource. Some resources may not load at all. The padlock icon in the address bar may show a warning.

Why it happens

Your site is served over HTTPS, but some resources (images, scripts, stylesheets, fonts) are loaded using http:// URLs. Browsers block or warn about these because mixing secure and insecure content undermines the security of the page.

The fix

Find and replace all http:// resource URLs with https://. Or better, use protocol-relative paths or root-relative paths:

<!-- Instead of this -->
<img src="http://example.com/image.jpg">

<!-- Use this -->
<img src="https://example.com/image.jpg">

<!-- Or for your own assets, use relative paths -->
<img src="/images/image.jpg">

If you are migrating from HTTP to HTTPS, add a Content-Security-Policy header to catch mixed content issues: Content-Security-Policy: upgrade-insecure-requests;. This tells browsers to automatically upgrade HTTP requests to HTTPS.

4. CORS Errors

What it looks like

Your JavaScript makes a fetch or XMLHttpRequest to an API and the browser console shows: Access to fetch at 'https://api.example.com' from origin 'https://yoursite.com' has been blocked by CORS policy.

Why it happens

Cross-Origin Resource Sharing (CORS) is a browser security feature. When your frontend at yoursite.com tries to call an API at api.example.com, the browser sends a preflight request to check whether the API allows requests from your domain. If the API does not include the right headers in its response, the browser blocks the request.

The fix

The fix must be applied on the API server, not your frontend. The API needs to include the Access-Control-Allow-Origin header in its response:

// Node.js / Express example
app.use((req, res, next) => {
  res.header('Access-Control-Allow-Origin', 'https://yoursite.com');
  res.header('Access-Control-Allow-Methods', 'GET, POST, OPTIONS');
  res.header('Access-Control-Allow-Headers', 'Content-Type, Authorization');
  next();
});

If you do not control the API, you have two options: use a server-side proxy (your backend calls the API and forwards the response to your frontend), or check whether the API offers a JSONP endpoint. Never use Access-Control-Allow-Origin: * on APIs that handle sensitive data.

5. "Not Secure" Warning in Browser

What it looks like

The browser address bar shows "Not Secure" next to your URL. On Chrome, it is a grey warning. On some browsers, it is a red padlock with a line through it. Visitors immediately lose trust.

Why it happens

Your site does not have an SSL/TLS certificate, or the certificate has expired, or it is not configured correctly. This means your site is served over HTTP instead of HTTPS. Since 2018, browsers have flagged all HTTP sites as insecure.

The fix

Install an SSL certificate. Most hosting providers offer free SSL through Let's Encrypt. On cPanel, look for "SSL/TLS" in the security section. On Vercel, Netlify, or Cloudflare Pages, SSL is automatic. After installing the certificate, force HTTPS by adding a redirect:

# .htaccess
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

If your certificate is installed but the warning persists, check for mixed content issues (see point 3 above) and verify the certificate covers your exact domain including the www subdomain if you use one.

6. Mobile Viewport Not Set

What it looks like

Your site looks like a tiny, zoomed-out desktop page on mobile devices. Users have to pinch and zoom to read anything. Google Search Console may report "Viewport not set" under the Mobile Usability section.

Why it happens

The viewport meta tag is missing from your HTML <head>. Without it, mobile browsers render the page at a default width of around 980px and then scale it down to fit the screen.

The fix

Add the viewport meta tag to every page's <head>:

<meta name="viewport" content="width=device-width, initial-scale=1.0">

This tells the browser to match the page width to the device width. Make sure your CSS also uses responsive techniques: relative units, media queries, and flexible layouts. If you are building a new website, this should be one of the first lines in every HTML file. It is a one-line fix that makes the difference between a usable mobile experience and an unusable one.

7. Slow Loading / Large Images

What it looks like

Your site takes five or more seconds to load. Google PageSpeed Insights gives you a score below 50. Visitors bounce before the page finishes rendering. The Network tab in DevTools shows image files that are 2MB, 5MB, or even larger.

Why it happens

The most common cause is unoptimized images. A photo straight from a camera or a stock photo site can easily be 4000x3000 pixels and 8MB. If your page loads six of those, the browser is downloading 48MB before it can render anything. Other causes include unminified CSS and JavaScript, too many third-party scripts, and no caching headers.

The fix

For images, convert them to WebP format and resize them to the maximum display size. A hero image that displays at 1200px wide does not need to be 4000px wide:

<!-- Use responsive images with srcset -->
<img
  src="hero-800.webp"
  srcset="hero-400.webp 400w, hero-800.webp 800w, hero-1200.webp 1200w"
  sizes="(max-width: 600px) 400px, (max-width: 1000px) 800px, 1200px"
  alt="Description of image"
  loading="lazy"
  width="1200" height="675"
>

Add loading="lazy" to images below the fold so they only load when the user scrolls to them. Minify your CSS and JavaScript. Set cache headers so returning visitors do not re-download assets. If speed optimization feels overwhelming, we cover this as part of our web design service because a fast site is not optional in 2026.

8. Favicon Not Showing

What it looks like

Your browser tab shows a generic globe or blank icon instead of your logo. It is a small detail but it makes your site look unfinished.

Why it happens

The favicon link tag is missing, the file path is wrong, or the file format is not supported by the browser. Some browsers are picky about caching, so even after adding a favicon, you may not see it immediately.

The fix

Add a favicon link in your <head>. SVG favicons work in all modern browsers and scale perfectly:

<link rel="icon" type="image/svg+xml" href="/favicon.svg">
<link rel="icon" type="image/png" sizes="32x32" href="/favicon-32x32.png">

Make sure the file actually exists at the path you specified. Open https://yoursite.com/favicon.svg directly in the browser to verify. If you are updating an existing favicon, browsers cache them aggressively. Append a query string to bust the cache: href="/favicon.svg?v=2". For full compatibility, also place a favicon.ico file in your root directory as a fallback for older browsers.

9. Form Not Submitting

What it looks like

A user fills out your contact form, clicks submit, and nothing happens. No confirmation, no error, no email. The form just sits there. This is one of the most expensive website errors because you are losing leads silently.

Why it happens

Several possible causes: the form's action attribute is missing or points to a broken endpoint. A JavaScript error is preventing the submit handler from firing. The form backend is rejecting the request due to CORS. Or the submit button is type="button" instead of type="submit".

The fix

Start by opening the browser console and submitting the form. Look for JavaScript errors or failed network requests. Check the basics:

<!-- Make sure your form has a valid action and method -->
<form action="https://yourbackend.com/api/contact" method="POST">
  <input type="text" name="name" required>
  <input type="email" name="email" required>
  <textarea name="message" required></textarea>
  <!-- Must be type="submit", not type="button" -->
  <button type="submit">Send</button>
</form>

If you are handling submission with JavaScript (fetch or XMLHttpRequest), make sure you call event.preventDefault() and that your error handling actually shows errors to the user instead of failing silently. Test the form endpoint directly with a tool like Postman to rule out backend issues. For businesses that depend on form submissions for leads, we always build in redundancy: email notification plus a CRM entry plus a WhatsApp alert, so no inquiry gets lost. If you are building a web application with complex forms, proper error handling is not a nice-to-have.

10. CSS Not Updating After Changes

What it looks like

You edit your CSS file, save it, refresh the page, and the old styles are still there. You triple-check the file. The changes are saved. But the browser refuses to show them.

Why it happens

Browser caching. When a browser loads a CSS file, it saves a local copy. On the next page load, it uses the cached version instead of fetching the updated one from the server. This is normally a good thing for performance, but it becomes a problem during development.

The fix

During development, use a hard refresh: Ctrl + Shift + R on Windows or Cmd + Shift + R on Mac. You can also open DevTools, go to the Network tab, and check "Disable cache" (this only works while DevTools is open).

For production, use cache busting by adding a version query string to your stylesheet link:

<!-- Cache-busted CSS -->
<link rel="stylesheet" href="/style.css?v=1.2">

<!-- Or use a build tool to add a hash -->
<link rel="stylesheet" href="/style.a1b2c3d4.css">

Build tools like Vite and Webpack do this automatically by appending a content hash to the filename. Every time the file changes, the hash changes, and the browser fetches the new version. If you are editing CSS on a live site without a build tool, incrementing the query string manually after each change is the simplest approach.

Prevention Is Cheaper Than Fixing

Every one of these common website errors is fixable. But the real cost is not the fix itself. It is the leads you lose, the visitors who bounce, and the trust you erode while the problem exists. A contact form that silently fails for two weeks could mean dozens of lost inquiries. A "Not Secure" warning could be turning away customers who would have converted.

The best approach is to catch these issues before your visitors do. Run regular audits. Check your site on mobile. Monitor your server logs. Test your forms. If that sounds like a lot, it is, and it is exactly what we do for every site we build and maintain at Arsyk Media.

Tired of Debugging Your Website?

We build websites that work correctly from day one, fast, secure, and error-free. Check out our web design services or get in touch to discuss your project.

View Our Packages →