---
title: "I Audited My Own Site's Technical SEO and Found a Bug That's Been Live the Whole Time"
description: "I audit clients' sites for technical SEO all the time and never once pointed the same tools at my own. Four minutes in, I found a duplicate- content bug that had been live since launch."
url: "https://mynerdylife.com/blog/www-apex-duplicate-content-bug/"
author: "Jared"
published: "2026-08-01"
category: "Raspberry Pi"
tags: ["nginx","technical-seo","cloudflare"]
---

# I Audited My Own Site's Technical SEO and Found a Bug That's Been Live the Whole Time

I do this thing where I'll happily spend an afternoon auditing a client's site for technical SEO issues and then never once point the same tools at my own. So this week I finally did, on mynerdylife.com, and about four minutes in I found something dumb: `mynerdylife.com` and `www.mynerdylife.com` were both serving the exact same content. No redirect. No canonical preference. Just two URLs, identical bytes, sitting there since launch.

If you've never run into this: it's a classic duplicate-content problem. Search engines see two URLs with the same content and have to guess which one you actually want indexed. Sometimes they guess right. Sometimes they split authority between both versions instead of consolidating it onto one. Either way, it's not a hypothetical SEO nitpick — it's a bug, and it had just been quietly costing me for however long the site's been up.

## How it happened

My nginx config for the site was one `server {}` block with both hostnames in `server_name`:

```nginx
server_name mynerdylife.com www.mynerdylife.com;
```

Totally reasonable-looking line. Totally wrong on its own, because nginx will happily serve identical content for both without you ever telling it that one should defer to the other. I'd added `www` to the `server_name` list at some point — probably out of habit, probably thinking "someone might type www, better cover it" — and then never finished the thought.

## The fix

Split it into two blocks. `www` gets nothing but a redirect:

```nginx
server {
    listen 127.0.0.1:80;
    listen [::1]:80;
    server_name www.mynerdylife.com;
    return 301 https://mynerdylife.com$request_uri;
}

server {
    listen 127.0.0.1:80;
    listen [::1]:80;
    server_name mynerdylife.com;
    # ... the actual site
}
```

The `$request_uri` matters — it preserves whatever path someone hit, so `www.mynerdylife.com/raspberry-pi/` redirects to `mynerdylife.com/raspberry-pi/`, not just the homepage. Small thing, but getting it wrong means every internal link from an old bookmark or a stray backlink dead-ends at your homepage instead of the actual page.

One extra wrinkle: my nginx sits behind a Cloudflare Tunnel with TLS terminating at Cloudflare's edge, so this whole thing is `http://` internally — no certificates to worry about here, just a straight host-based redirect.

## Checking it actually worked

```bash
$ curl -sI -H "Host: www.mynerdylife.com" http://127.0.0.1:80/
HTTP/1.1 301 Moved Permanently
Location: https://mynerdylife.com/
```

Then the same thing against the real, public hostname, through Cloudflare, to make sure nothing was different at the edge:

```bash
$ curl -sI https://www.mynerdylife.com/
HTTP/2 301
location: https://mynerdylife.com/
server: cloudflare
```

Clean 301 both ways. One canonical host, and Google (or whoever) never has to guess again.

## The actual lesson

Run your own audit. Not the client's, not the "someday" project — the site you already believe is fine, because you set it up, so obviously it's fine. It wasn't. It had been living with a duplicate-content bug since the first day the `www` DNS record existed, and it took literally minutes to find once I actually looked instead of assuming.

(I found a couple of other issues in that same pass — [more on those next](https://mynerdylife.com/blog/security-headers-through-a-cloudflare-tunnel/).)