Microsite SEO is more complicated than standard guides suggest. The decisions that determine whether your microsite helps or hurts your search presence — domain architecture, canonical configuration, indexation strategy — have no direct equivalents on a conventional website.
Most SEO advice treats “optimize your microsite” as a straightforward extension of website best practices. It isn’t. Microsites introduce choices that regular websites don’t, and the wrong choice can actively damage your main domain’s rankings even when individual pages look technically clean.
This guide covers the distinct SEO challenges microsites present and the right decision at each step.
Why microsite SEO is different from website SEO
A standard website is one domain, one index, one authority pool. When you publish new pages, they inherit the domain’s accumulated authority and contribute their own signals back to it.
Microsites break this model in two important ways.
First, a microsite can live in several different technical relationships with your main domain — a separate domain (microsite-topic.com), a subdomain (info.yourcompany.com), or a subfolder (yourcompany.com/campaign/). Each configuration creates a different relationship between the microsite’s content and your main domain’s SEO performance. The distinctions aren’t subtle: the architecture choice can mean the difference between a microsite that builds ranking authority and one that dilutes it.
Second, many microsites are not meant to rank at all. A sales proposal microsite sent to a specific prospect should not appear in Google when someone searches for your competitor’s clients. An RFP response microsite sent to five procurement evaluators should not be indexed anywhere. Applying standard “optimize everything” SEO logic to these private microsites creates competitive exposure and privacy risks that most teams don’t notice until it’s too late.
Microsite SEO done well starts with answering one question clearly: should this microsite rank on Google?
Step one: decide whether your microsite should rank at all
Before making any optimization decision, place your microsite in one of two categories:
Public microsites that should rank:
- Event and conference landing pages targeting relevant search queries
- Product launch hubs covering a specific topic with depth
- Campaign landing pages aimed at a keyword-defined audience
- Resource and topic hubs designed to attract organic traffic
Private microsites that should not be indexed:
- Sales proposals sent to specific prospects
- RFP responses
- Client onboarding portals
- Partner-only resources
- Internal training materials or employee-facing content
The second category is where most companies make SEO mistakes — not through under-optimization, but through accidental indexation. A sales proposal microsite that gets indexed by Google exposes your pricing, strategy, and client targeting language to anyone who searches the right terms. It also sends outbound links from an uncontrolled URL, which affects how crawlers interpret your site architecture.
The mechanism to prevent accidental indexation is straightforward: add <meta name="robots" content="noindex, nofollow"> to the <head> element of every private microsite page. Many microsite platforms don’t set this by default, meaning public indexation is the default state unless someone explicitly changes it.
Domain, subdomain, or subfolder: the architecture decision that shapes everything else
For microsites that should rank, no single decision affects long-term SEO performance more than the hosting architecture choice.
Separate domain (microsite-topic.com)
A new domain starts from zero — no inherited authority, no existing backlinks. Even a well-optimized microsite on a fresh domain will take months to rank for any competitive keyword because the domain itself needs to earn authority before its content can rank. Separate domains make sense only when the microsite is intended as a permanent, independent brand with its own long-term SEO investment. For campaign microsites, product launches, or event pages, a separate domain is almost always the wrong choice.
Subdomain (campaign.yourcompany.com)
The most common misunderstanding in microsite architecture is that subdomains inherit authority from the main domain. They don’t, at least not automatically. Google’s crawlers treat subdomains as distinct sites from the root domain. A microsite at campaign.yourcompany.com needs to earn its own authority even if yourcompany.com has a strong backlink profile. Link equity does not automatically flow between them.
Subdomains work well when the microsite covers content genuinely different enough from the main site that hosting it separately makes sense structurally — a support portal, a community site, or a developer documentation hub. For marketing microsites that are extensions of the main domain’s topic, subdomains dilute rather than build authority.
Subfolder (yourcompany.com/campaign/)
This is the strongest configuration for SEO. Content in a subfolder is fully within the main domain’s index. It inherits the domain’s accumulated authority, contributes new keyword signals and backlinks back to the root domain, and avoids splitting link equity. When organic ranking performance is a priority, subfolder-hosted microsites consistently outperform equivalent subdomains.
The practical constraint: subfolder hosting requires integration with the main domain’s CMS or infrastructure, which is often slower to configure than launching a standalone subdomain. For many teams, the speed advantage of separate hosting outweighs the SEO trade-off — but the decision should be deliberate, not the result of defaulting to whatever the microsite platform provides.
Ready to go digital?
Discover how Zoomforth can help you.
Join 500+ enterprise sales, marketing and HR teams building trackable microsites — no developer needed.
Rated 4.5/5 on G2 · Trusted by Fortune 500 teams
Canonical tags: how to share content without splitting authority
If your microsite reproduces content that also exists on your main website — adapted product descriptions, republished blog sections, reused case study copy — canonical tags prevent search engines from treating the duplication as competing versions of the same content.
The canonical tag (<link rel="canonical" href="preferred-URL">) in the page’s <head> tells Google which version of a piece of content should receive ranking credit. Without it, when two URLs contain identical or substantially similar content, Google may index neither version reliably or may index the wrong one.
Three canonical scenarios come up regularly with microsites:
Microsite content duplicated from the main site
If your microsite includes copy that also lives on your main domain — a product description, a case study, an about section — the microsite page should carry a canonical pointing to the main domain version. This preserves the main site’s ranking for that content and prevents the microsite from accidentally outranking the primary page.
New content created for a microsite that may later move to the main site
Consider the canonical relationship before you publish. If you publish content first on the microsite and later reproduce it on the main domain without updating the canonical tag, the microsite URL gets ranking credit — not the main domain page you intended to rank. Plan the canonical relationship before publishing, not as a cleanup task afterward.
Content created for the microsite that will stay on the microsite
For genuinely new content that you want to rank at the microsite URL, no explicit canonical is needed — pages without a canonical tag default to self-referential canonical behavior. Just avoid the first two scenarios.
On-page SEO for microsites: the short checklist
For public microsites, standard on-page signals still apply. Microsites are simpler than full websites because most target one or two keywords rather than dozens. The fundamentals are fewer, but they matter more on a page that has little other content to offset a weak signal.
Title tag: 50–60 characters. Primary keyword at the start. Brand name at the end. Each page in the microsite needs a unique title tag — not the same title repeated across every section.
Meta description: 150–155 characters. The keyword should appear in the first 10 words. Write it as a CTA rather than a summary; it determines whether searchers click.
H1: One per page. Contains the primary keyword. Matches the page’s actual topic. The H1 and title tag can differ — the title tag optimizes for click-through, the H1 confirms the page’s topic to the reader.
Content depth: Thin pages (under 300 words) struggle to rank for competitive queries. Event pages, campaign landing pages, and resource hubs frequently underestimate the content depth Google expects. If the microsite targets a keyword with meaningful search volume, the page needs to substantively answer the query associated with that keyword — not just introduce a product.
Internal links: Every public microsite page should link back to relevant content on the main domain at least once. This creates a crawl path from the microsite to the main site and signals to search engines that the two properties are related.
Page speed: Microsites hosted outside the main domain’s infrastructure often inherit slower server performance. Google’s Core Web Vitals affect ranking. Test the microsite with PageSpeed Insights before launch.
Controlling indexation: how to block Google without breaking your microsite
For private microsites, the priority is not optimization but prevention. Three mechanisms work reliably.
noindex meta tag (recommended)
Add <meta name="robots" content="noindex, nofollow"> to the <head> of every private microsite page. This is the most reliable signal to Google not to index the page. Most enterprise microsite platforms surface this as an access control setting — verify that it’s active before sending any proposal or RFP response.
robots.txt disallow
Adding the microsite’s path to robots.txt prevents Googlebot from crawling the page. The important limitation: robots.txt prevents future crawling but does not remove a page already in Google’s index. Use the noindex tag as your primary mechanism; robots.txt as a secondary layer.
Password protection
For the most sensitive microsites, password-gating is the most complete defense against indexation. Google cannot index content it cannot access. Most enterprise microsite platforms support password protection or access control at the page or site level.
One approach that does not work: simply not promoting a URL publicly. Search engines discover pages through links, sitemaps, and crawl behavior. A private microsite with no noindex tag that links back to your main site will eventually be crawled and indexed, regardless of whether you shared the URL publicly.
How microsites can build — not drain — your main domain’s authority
Microsites are sometimes treated as SEO liabilities to manage, when public microsites configured correctly are actually assets.
A well-built public microsite on a subfolder contributes new keyword rankings, earns backlinks that flow directly to the main domain, and adds crawl paths through internal linking. An event microsite that earns press coverage generates backlinks at a different URL profile than your main site’s typical PR patterns — this diversification is useful for domain authority.
Internal linking between microsites and the main website also improves site architecture. A product launch microsite that links to related main-domain content — product pages, case studies, pricing — improves crawl efficiency and passes authority through those connections.
The guiding principle is simple: public microsites should be treated as part of your main domain’s SEO strategy, not as standalone assets managed in isolation. Private microsites should be actively excluded from it, with noindex set as a default rather than an afterthought.
If you’re building client-facing microsites — proposals, onboarding portals, RFP responses — and want to understand how Zoomforth handles access controls and indexation defaults by default, see how the platform works.
Ready to build microsites that rank when they should — and stay private when they shouldn’t? Request a demo.
