The Tribute Microsite: When robots.txt Points at Another Domain on Purpose

I came across a small Netlify-hosted page last week. A "hall of fame" microsite. One subdomain on a personal .tech root, four hundred lines of React, a single bundled stylesheet. What caught my eye was the robots.txt:

User-agent: *
Allow: /

Sitemap: https://OTHER-SUBDOMAIN.example.tech/sitemap.xml

The robots.txt is on tribute.example.tech. The Sitemap directive points at master.example.tech. The sitemap.xml of the tribute site, when I fetched it, was identical: it listed only the master site's URL with a <lastmod> and a priority. No URL on the tribute domain itself appeared in either file.

To a junior SEO this looks like a bug. It is not a bug. It is the tribute-microsite pattern, and when you use it on purpose, it solves a specific class of problem.

What's actually happening

A tribute microsite is a focused, narrative sub-domain that exists to celebrate, document, or amplify a single milestone or campaign. It is small, often static, often single-page. It has its own URL because the URL is the brand asset (a hashtag, a campaign name, a dated milestone). The owner does not want the tribute site to compete with their main site for crawl budget, indexing priority, or topic authority. They want every signal funneled back.

Three signals together make the funnel:

1. robots.txt Sitemap directive points at the master. Crawlers that follow the directive go discover the master's URLs.
2. sitemap.xml on the tribute lists only master URLs. The tribute doesn't claim its own pages as canonical-anywhere.
3. canonical link on the tribute page points at the master's home (or the relevant master page). This part is critical and often missed; without it, Google still indexes the tribute on its own merits and you have a duplicate-authority split.

The site I was looking at had #1 and #2 but not #3. Their tribute page had <link rel="canonical" href="https://tribute.example.tech/" />, claiming itself as canonical. Pieces 1 and 2 say "look elsewhere"; piece 3 says "actually I'm the source." Mixed signals confuse the crawler. If you want the funnel to work, all three have to agree.

When this pattern works

• Time-bound campaigns. A "100 days of building" series, a hackathon recap, a product-launch landing page that's relevant for six weeks. The microsite carries the narrative. The master carries the topic authority.
• Naming wins you couldn't get on the main site. You wanted awesome-launch.com. It was taken. You shipped on launch.yourname.com instead. The microsite uses the prettier URL; the funnel keeps your main domain's authority intact.
• Brand isolation for risky content. Demos, betas, satire, anything you don't want to inherit your main site's sober tone. The microsite gets to be off-brand without polluting the master's indexed content.
• Milestones and tributes. Year-in-review pages, anniversary recaps, "thank you" pages to a community. They want a permanent URL but shouldn't dilute crawl priority on your main site.

When this pattern hurts you

• Long-form content the microsite produces. If the tribute site has actual articles, real evergreen value, and pages that should rank on their own, funneling everything back kills its standalone discoverability. Use it only when the microsite's job is to point elsewhere.
• You forgot piece #3. A robots.txt sitemap-pointer with a self-canonical on the tribute page is the duplicate-authority trap. Search engines see the master URLs in the sitemap AND the tribute pages on their own URLs, both claiming to be the source. Authority splits. Both sites lose.
• You added the master's sitemap as a rewrite, not a directive. Some platforms support /sitemap.xml → https://master.example/sitemap.xml 301. A 301 redirect on the sitemap path is interpreted by some crawlers as "the sitemap moved" and they update their sitemap-of-record to the new URL. This is good. By others it's interpreted as a misconfigured server. Use a directive in robots.txt, which is unambiguous.
• You lost track of which domain owns what content. Keep the master site authoritative on topics. Keep the microsite authoritative on the campaign. Don't blur. If the microsite starts to acquire its own backlinks and traffic patterns, you've outgrown the pattern, and it's time to reconsider the architecture.

The minimum config to do this right

Tribute site tribute.example.com:

# robots.txt
User-agent: *
Allow: /

Sitemap: https://master.example.com/sitemap.xml

<!-- sitemap.xml — list only master URLs you want crawled
     OR omit and rely on the robots.txt directive alone. -->
<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://master.example.com/</loc>
    <lastmod>2026-04-23</lastmod>
    <priority>1.0</priority>
  </url>
</urlset>

<!-- on every tribute page, in <head> -->
<link rel="canonical" href="https://master.example.com/" />

Three pieces. Two files plus one tag. Together they say: "this site exists, it's accessible, but the indexable, rankable content lives at the master URL."

How to verify the funnel is working

After deploying, give Google a week to recrawl, then run:

# 1) Robots directive resolves
curl -sS https://tribute.example.com/robots.txt | grep Sitemap

# 2) Tribute sitemap returns the right XML, not an SPA shell
curl -sS https://tribute.example.com/sitemap.xml | head -20

# 3) Tribute page canonical points at the master
curl -sS https://tribute.example.com/ \
  | grep -oE '<link[^>]+rel="canonical"[^>]*>'

# 4) Search Console URL Inspector on the tribute page should report
# "Indexed: not for the canonical URL" — the master gets the credit.

If all four agree, the funnel is wired. If any one disagrees, fix the disagreement before letting the campaign run.

Why this matters more than the textbook says

Standard SEO advice treats cross-domain canonicalization with suspicion because it's how spammers used to launder backlinks. The shape is the same; the intent is different. The shape: a network of microsites pointing at a master. The bad version is automated PBN scaffolding designed to manipulate ranking. The good version is a deliberate marketing move where the publisher transparently routes credit to the master domain they control.

Google's docs and the search community have, over the last three years, gotten more comfortable distinguishing the two. Cross-domain canonical with consistent sitemap signals and matching topical content is now treated as a valid pattern. Cross-domain canonical with inconsistent signals or unrelated content is still suspicious.

The tribute microsite, done right, is on the safe side of that line.

I covered campaign-architecture and the trade-off between authority concentration and microsite separation in The $20 Dollar Agency, the second book in the Digital Empire trilogy. Chapter 9 walks through three campaign patterns (one master / many microsites, network of equals, hub-and-spoke) and which one fits which goal.

Related reading

• Cross-Domain Entity Consistency covers the related case where a brand operates across multiple domains and needs them to look like one entity to AI search.
• Sitemap Audit and Cross-Domain Link Hygiene check whether your inter-domain linking matches your stated architecture.
• Sitemap Lastmod Truthfulness covers the related sitemap-credibility issue: if the lastmod isn't accurate, neither funnel nor master gets the freshness signal.
• The SPA Shell Trap covers the case where a tribute microsite's sitemap.xml is silently swallowed by the catch-all and returns the SPA HTML.
• The Mega Analyzer reports cross-domain canonical and Sitemap-directive mismatches in the Indexing Hygiene tab.

Fact-check notes and sources

• robots.txt Sitemap directive specification: Google Search Central, robots.txt syntax.
• Cross-domain canonical handling: Google Search Central, Consolidate duplicate URLs.
• Sitemap protocol (locations and cross-domain references): sitemaps.org spec, location of sitemap files.
• Source site identifying details have been redacted. The pattern described here generalizes to any subdomain hosted on a static platform that supports _redirects and a robots.txt deploy file.

This post is informational, not SEO consulting advice. Cross-domain signal architectures interact with your existing site's authority in ways specific to your situation.