When your name is also a thing: entity SEO for an ambiguous name

claytoncamera — Tue, 28 Jul 2026 20:24:44 +0000

My surname is a device, and the Claytons that outrank me are towns. Three of them turned up on page one as traffic and weather cams. So the exact query “Clayton Camera” returns municipal webcams, a YouTube channel of webcam feeds, and a photography business — and, until recently, nothing of mine at all.

That sounds like a keyword problem. It isn’t. It’s an entity disambiguation problem, and the two have completely different fixes. Writing more content aimed at the query is wasted motion. Here’s what I did instead, what it cost, and what I’d tell anyone whose name collides with a common noun, a place, or a product.

First: measure it signed out

I started from a false premise — “only my LinkedIn shows up when you search my name.” It doesn’t. I saw LinkedIn because I was signed in to Google with a profile that has visited it a hundred times. That’s personalization, not rank.

Non-personalized, the first page for the bare two-word query was: traffic and weather cams for Clayton NY, Clayton NC and Clayton CA; a “Cameras of Clayton NY” channel; a photography company; two unrelated photographers. Zero results for me — not even the LinkedIn profile I thought was ranking.

Rule 1
Never audit your own name signed in. Your search history is precisely the data that makes a bad SERP look fine. Incognito, signed out, or it didn’t happen.

The measurement also found the one thing that was working: a small client-work site of mine ranked #1 for the query “Clayton Camera LoopholeMaxing OrbitRoute founder.” Google already had that page and understood it. That was the beachhead — and, tellingly, it was the property with the least SEO wiring on it: no canonical, no structured data, no sitemap, and a robots.txt advertising a sitemap that returned 404.

The reframe

Content volume does not beat three towns’ worth of municipal infrastructure for a generic two-word phrase. What beats it — or at least gets you onto the board next to it — is making search engines build an entity: a single node in the knowledge graph that means “Clayton Camera, the person in Orlando,” distinct from “camera, in Clayton.”

An entity is convincing when many independent sources say the same thing about the same identifier. So the work splits in two: give the entity one unambiguous identifier, then attach everything you own to that exact identifier — identically.

The playbook

1. One page whose title, H1, URL and canonical are the name

Not “About me.” Not “Home.” The literal string. I registered the exact-match domain, which is the strongest version of this — but a /your-name/ path on a domain you already own does the same job. Give it ProfilePage + Person markup and make the person the mainEntity of the page.

2. One Person `@id`, referenced everywhere and redefined nowhere

This is the load-bearing part. Every property I own emits a Person node using the same identifier:

{
  "@type": "Person",
  "@id": "https://claytoncamera.com/#person",
  "name": "Clayton Camera",
  "url": "https://claytoncamera.com/"
}

My company sites reference it as the founder of their Organization node. My portfolio site references it as the page’s subject. The entity page itself defines it in full — image, address, knowsAbout, sameAs, worksFor.

Mint a second identifier on any one of those sites and you have not added a signal — you have split one person into two half-evidenced strangers. This is the single easiest way to undo months of work, and it happens by accident, usually during a redesign.

3. Say out loud what you are not

Schema.org has a property for exactly this situation and almost nobody uses it:

"disambiguatingDescription": "Clayton Camera is a person — a technical
  founder and software engineer based in Orlando, Florida. Not to be
  confused with traffic or weather cameras in the towns of Clayton,
  New York; Clayton, North Carolina; or Clayton, California."

It reads blunt because it is. It is also the most on-the-nose anti-collision signal available, and it’s the sentence an AI answer engine can quote when someone asks who you are.

4. Make every rendered link real, not just marked up

sameAs is a claim. A crawler follows links. So each profile in sameAs also appears as a visible rel="me" anchor on the page, and each company site carries a visible “Founded by [name]” link back to the entity page — not only the JSON-LD. Schema without a rendered counterpart is a weaker version of the same statement.

5. Off-site, use one string

Same name spelling, same role line, same city string, same link, on every profile you claim. Consistency is not an aesthetic preference here — matching strings across independent sources is literally the mechanism by which mentions get merged into one entity. Varying your job title across five profiles is how you stay five weak entities.

Two traps I hit

Moving the identifier. I built the hub at /clayton-camera/ on an existing domain, then bought the exact-match domain hours later and moved it. That was only free because the page had never been indexed. The move touched four files across three repositories in a single commit — if two of them disagree even briefly, the crawl that lands in that window sees two entities. The old path became a stub with a cross-domain canonical and noindex,follow, never a live duplicate.

A single public resolver is not the truth. After the DNS change, one major public resolver served the old parking IPs long enough that I briefly concluded the records had reverted. The authoritative nameservers and a second public resolver had been correct the whole time. Check authoritative and a second resolver before you diagnose a regression — and prove the origin independently of DNS entirely:

curl --resolve example.com:443:185.199.108.153 https://example.com/

That separates “my host is misconfigured” from “DNS hasn’t propagated,” which look identical from a browser.

Then guard it in CI

Entity work rots silently. Nothing errors when a sitemap goes stale, a private path leaks into it, or a well-meaning refactor mints a second Person id. So the assertions live in a shell script that runs with the tests:

robots.txt and sitemap.xml agree, and every public page is listed
zero disallowed/internal paths appear in the sitemap
the entity page’s title starts with the name, its h1 is the name, it self-canonicalises
disambiguatingDescription is present
exactly one Person @id exists tree-wide
every JSON-LD block parses
the redirect stub is still a stub and has not been re-expanded into a competing page

That last one matters more than it looks. Two pages competing for the same name query is exactly the problem canonicalisation exists to prevent, and “let’s bring that old page back” is a reasonable-sounding request six months from now.

Honest expectations

Displacing three towns’ worth of public webcams for a bare two-word generic query is a 3–6 month job and may never fully clear. Anyone selling you a two-week version of this outcome is selling you the signed-in SERP.

The realistic — and more valuable — win is different: the name plus almost any qualifier (founder, Orlando, the company names, developer) returns your properties, and the person entity resolves correctly in AI answer engines, which increasingly matter more than position 4 on a page nobody scrolls.

The on-site work took an afternoon. From there the rate limiter is off-site citations — profiles you claim, work you publish under the byline, people who link to you because you made something worth linking to. There is no schema property for that part.

The one-line version
Before doing any keyword work on a personal-name query, check whether the name is an ambiguous entity. If it collides with a common noun, a place, or a product class, no amount of content wins — one canonical @id, a page that is the name, an explicit statement of what you are not, and consistent citations off-site are the whole fix.

DEV Community: claytoncamera