Mime Type

MIME Type Validation

Incorrect MIME types cause browsers to block stylesheets and scripts (MIME sniffing is disabled by X-Content-Type-Options: nosniff), breaking page rendering and signalling poor site quality to crawlers.

Quick Reference

• The Content-Type header must match the actual file type being served
• HTML pages must be served as text/html; charset=utf-8
• CSS files must be served as text/css and JavaScript as text/javascript
• Incorrect MIME types cause browsers to block or mishandle resources

Check

For key pages and their linked resources, inspect the HTTP Content-Type response header. Verify HTML responses use text/html; charset=utf-8, CSS uses text/css, JS uses text/javascript, and images use image/jpeg, image/png, etc.

Fix

Update your server configuration to serve each file type with its correct MIME type. Set X-Content-Type-Options: nosniff to prevent browsers from guessing content types. In Next.js and similar frameworks, configure headers in next.config.js.

Explain

The Content-Type header tells browsers and crawlers what kind of content is being sent. When it mismatches the actual file type, browsers either block the resource or render it incorrectly—CSS served as text/plain won't be applied, and JavaScript served as text/html may be blocked by strict MIME checking.

Code Review

For HTML, CSS, and JS assets, check the Content-Type response header. Verify HTML responses include 'charset=utf-8'. Check that X-Content-Type-Options: nosniff is set. Flag any resource returning Content-Type: text/html that is not an HTML page. Check for missing charset declarations on text responses.

---

For full implementation details, code examples, and framework-specific guidance, see references/rule.md.

Rule page: https://frontendchecklist.io/en/rules/seo/mime-type

MIME Type Validation

Detects Content-Type header mismatches with file extensions

Priority: medium · Difficulty: intermediate · Time: 15 min

--- The Content-Type HTTP response header tells the browser and search crawlers what type of content is in the response body. MDN's MIME type reference and the IANA registry both matter here, because a mismatch can break rendering and undermine crawl quality.

Code Example

# Check a page's Content-Type header
curl -I https://example.com/page

# Check a CSS file
curl -I https://example.com/styles/main.css
# Expected: content-type: text/css

# Check a JS file
curl -I https://example.com/js/app.js
# Expected: content-type: text/javascript

Why It Matters

Incorrect MIME types cause browsers to block stylesheets and scripts, especially when `X-Content-Type-Options` disables sniffing. That turns a server-header mistake into a visible rendering failure.

Common Correct MIME Types

Common Misconfigurations

# ❌ Bad: CSS served as text/plain
HTTP/1.1 200 OK
Content-Type: text/plain

# ✅ Good: CSS served correctly
HTTP/1.1 200 OK
Content-Type: text/css

# ❌ Bad: JS served as text/html
HTTP/1.1 200 OK
Content-Type: text/html

# ✅ Good: JS served correctly
HTTP/1.1 200 OK
Content-Type: text/javascript

Nginx Configuration

# nginx.conf or mime.types
include /etc/nginx/mime.types;

# Ensure charset is set for HTML
charset utf-8;

Next.js / Vercel

Next.js automatically sets correct MIME types for static assets. For custom headers:

// next.config.js
module.exports = {
  async headers() {
    return [
      {
        source: '/api/:path*',
        headers: [
          { key: 'Content-Type', value: 'application/json; charset=utf-8' },
        ],
      },
    ]
  },
}

Security: MIME Sniffing

Always set X-Content-Type-Options: nosniff to prevent browsers from guessing content types when headers are wrong:

add_header X-Content-Type-Options "nosniff" always;

Without this header, a browser may execute a file uploaded as an image if it detects JavaScript content—a security vulnerability.

With X-Content-Type-Options: nosniff (a security best practice), browsers will refuse to execute CSS or JavaScript served with the wrong MIME type. This is the correct behaviour—fix the server config rather than removing the security header.

Exceptions

• Staging, utility, login, account, or internal search pages may intentionally use different crawl or index signals if they are not meant to rank.
• Temporary migration states can produce noisy intermediate signals; flag the live production URL pattern, not one-off transition artifacts.
• When redirects, canonicals, robots directives, or indexability signals conflict, fix the strongest final signal first instead of reporting every downstream symptom as a separate blocker.

Standards

• Use these references as the standard for the final search-facing HTML, metadata, and crawl behavior.
• Check the implementation against MDN: MIME types (IANA media types) before treating the rule as satisfied.
• Check the implementation against MDN: X-Content-Type-Options before treating the rule as satisfied.

Verification

Automated Checks

• Inspect rendered HTML and HTTP headers to confirm the expected metadata or crawlability signal is present.
• Test the affected URL with Google Search Console or equivalent tooling where relevant.
• Re-crawl a representative page set after deployment.

Manual Checks

• Confirm the change does not create conflicting canonical-url, robots, or structured-data signals.