Cross-domain reputation linking strategy

Context

Running multiple domains creates a fragmentation problem: each domain builds its own reputation independently. Search engines, LLMs, and humans visiting one site have no structured way to know that the same person runs the others.

The wardleymaps.com integration into kda.zone exposed the pattern. wardleymaps.com has been running since 2013 with a community forum, curated resource list, and mapping tools — but none of that reputation flowed to kda.zone, and vice versa.

Alternatives considered:

• Single domain for everything. Rejected. Separate domains serve separate audiences (strategy practitioners vs personal brand vs project audiences). Merging dilutes focus and breaks audience expectations.
• Informal mentions only. Insufficient. Humans can follow prose links, but search engines and LLMs need structured signals to understand identity ownership across domains.
• Social login / OAuth identity. Overkill for static sites. The problem is discoverability, not authentication.

Decision

Every time a new domain is added to the content farm, or an existing external domain is claimed as "mine," apply this checklist on both sides of the link:

On the hub site (kda.zone)

1. rel="me" in footer link. The footer link to the project domain must include rel="me noopener" in sites.yaml. This is the HTML-level identity ownership signal recognised by IndieWeb, search engines, and increasingly by LLMs.

2. Schema.org Person with sameAs. The author block in sites.yaml must list the project domain in sameAs. The engine emits this as a Person in JSON-LD on every page. This is the structured-data signal that tells machines "this person is the same entity that runs these other domains."

3. Content-level attribution. The hub site's about page and projects page must name the project with concrete reputation signals — not just "I run X" but what X is, how long it has been running, and what it contains (community, tools, guides, user base). Vague references don't transfer reputation.

4. llms_description. The hub site's llms_description in sites.yaml must explicitly name the project domain and the relationship. LLMs use llms.txt as a primary discovery mechanism; if the connection isn't stated there, it may as well not exist.

On the project site (e.g. wardleymaps.com)

5. Reciprocal rel="me" link back to kda.zone. Without this, the hub's claim is unverified. Bidirectional rel="me" is what search engines treat as a confirmed identity link.

6. Schema.org author block. The project site's JSON-LD should include an author with url: "https://kda.zone" and sameAs pointing back to the hub. This closes the structured-data loop.

7. llms.txt or about page attribution. The project site should name the maintainer with a link to kda.zone. This makes the relationship discoverable by LLMs crawling the project site.

Verification

After applying the checklist, verify:

• Build the hub site (bun run build) and inspect the JSON-LD in the rendered HTML for correct Person and sameAs output.
• Inspect the footer HTML for rel="me noopener" on the project link.
• Check dist/<domain>/llms.txt for the explicit relationship statement.
• On the project site, verify the reciprocal rel="me" and author attribution.

Consequences

• Every new domain or external claim requires work on both sides. This is intentional — unverified one-way claims are weak signals. The overhead is small (a few lines of config and content) but must not be skipped.
• sites.yaml gains an author block. Currently only used on the personal site, but available for any site that needs authorship attribution. The engine reads site.author.sameAs to emit Person JSON-LD.
• Content pages must be updated, not just config. Structured data alone is not enough. Human-readable about/projects pages must tell the story with specifics. This means content updates are part of the linking process.
• External sites not managed in this repo need separate changes. The checklist documents what must happen on both sides, but only the hub-side changes can be automated here. Project-side changes are a manual step until the project is brought into the content farm.
• The checklist is ordered by impact. If you can only do one thing, bidirectional rel="me" (steps 1 and 5) is the highest-value signal. Schema.org sameAs (steps 2 and 6) is second. Content and llms.txt (steps 3, 4, 7) reinforce but don't substitute for the structured signals.