Skip to content
Blazej Mrozinski

SEO Architecture Before Your First Visitor

Blazej Mrozinski · · Product
growth-engineering
SEO Architecture Before Your First Visitor

Google indexed my personal site within four hours of the first deploy. No manual submission. No “fetch and render” ritual in Search Console. No waiting days for crawl bots to discover the domain. The site announced itself.

That speed was not an accident or a lucky crawl. It was the result of a deliberate decision to build search engine infrastructure into the site’s foundation before there was any content to optimize. IndexNow pings, structured data schemas, multi-sitemap configuration, consent-aware analytics, social sharing images, redirect handling. All of it was in place before the first blog post was written.

This runs counter to how most people approach SEO. The standard playbook says: build your site, write your content, then optimize for search. Maybe hire an SEO consultant after you’ve been publishing for six months and wonder why nobody’s finding you. I’ve spent enough time in the growth engineering space to know that this sequence is backwards, and that the cost of retrofitting SEO infrastructure is substantially higher than building it in from the start. That said, I’m drawing primarily from content-heavy personal and small-business sites. If you’re building a SaaS dashboard with three static pages, the calculus may look different.

Table of Contents

The Retrofitting Tax

There is a specific kind of technical debt that accumulates when SEO is treated as an optimization layer rather than a structural component. I call it the retrofitting tax, and it compounds in ways that aren’t immediately obvious.

Consider a site that launches with a default single sitemap. Six months later, it has 80 pages across blog posts, project pages, standalone pages, and publication listings. The single sitemap file works, technically. Search engines can parse it. But it gives crawlers zero signal about which content types matter, how frequently different sections update, or where to prioritize their crawl budget. Switching to a multi-sitemap architecture after the fact means changing URL structures, setting up proper redirects so the old sitemap URL doesn’t 404, and hoping that search engines pick up the change without any indexing disruption.

Now multiply that by every SEO infrastructure decision you deferred. Structured data that needs to be retrofitted across dozens of page templates. Analytics configurations that require re-tagging. Social sharing images that need to be generated for a back-catalog of posts. Each individual task is manageable. The aggregate is a project unto itself, and it competes for time with the actual content creation that drives the site forward.

You might reasonably ask: why not just fix these things incrementally as the site grows? In theory, that works. In practice, I’ve seen it repeatedly deprioritized because the site is “working fine” without it. The migration cost grows quietly in the background.

The alternative is to absorb this work once, at the foundation layer, when the site has zero content and zero visitors. The marginal cost of adding SEO infrastructure to a site with three pages is negligible compared to retrofitting it onto a site with three hundred.

What SEO Architecture Actually Means

When I say “SEO architecture,” I don’t mean keyword research or content strategy. Those are important, but they operate at a different layer. SEO architecture refers to the structural decisions that determine how search engines discover, understand, categorize, and present your content. It’s the plumbing that makes optimization possible.

For my personal site, this meant six specific systems, each built before the first visitor arrived.

The distinction matters because most SEO advice conflates strategy with infrastructure. “Write compelling meta descriptions” is strategy. Building a system where every page type automatically generates a properly formatted meta description from its content schema is infrastructure. The first requires ongoing attention for every piece of content. The second requires one-time effort that then works automatically.

IndexNow: Teaching Your Site to Announce Itself

The traditional model of search engine indexing is passive. You publish a page, and eventually a crawler finds it. “Eventually” might mean hours, days, or weeks depending on your domain authority, crawl frequency, and how the search engine’s scheduler feels about your site that day.

IndexNow flips this model. When a page is published or updated, the site sends an HTTP request to participating search engines (Bing, Yandex, and others through the IndexNow protocol) with the URL that changed. The search engine doesn’t have to discover the change. It’s told directly.

I integrated IndexNow at the build level. Every deploy automatically submits changed URLs. This means that publishing a blog post and having it eligible for indexing are functionally simultaneous events. There’s no gap between “content exists” and “search engines know content exists.”

For a new site with no crawl history and no domain authority, this matters enormously. Without IndexNow, you’re dependent on search engines deciding your site is worth crawling frequently. With it, you’re ensuring that every piece of content gets its chance to be evaluated on merit rather than being delayed by crawl scheduling. Worth noting: IndexNow guarantees faster notification, not faster ranking. The content still has to earn its position. But it removes the discovery bottleneck, which for a brand-new domain can be the longest wait.

Multi-Sitemaps and Crawl Budget Reality

Every search engine allocates a crawl budget to your domain. This is the number of pages it’s willing to fetch and process within a given time window. For large sites, crawl budget management is a well-understood discipline. For small sites, most people don’t think about it at all.

For a site of my size, crawl budget is admittedly not a pressing constraint. The honest reason I built multi-sitemaps early is structural clarity: it tells crawlers something useful about the site’s content topology, and it avoids a migration later if the site grows to a point where crawl budget does matter.

A single monolithic sitemap tells a search engine “here are all my URLs” with no additional context. A multi-sitemap architecture tells it “here are my blog posts (updated frequently), here are my project pages (updated occasionally), here are my static pages (rarely change), and here are my publications (growing collection).” Each sitemap carries its own lastmod timestamps and change frequency hints.

I replaced the default single sitemap with a multi-sitemap setup during the initial build. The main sitemap index file at the standard URL points to individual sitemaps for each content type. This required a 301 redirect from the original sitemap URL to the new index URL, which is a trivial detail during initial setup but a migration headache if you wait until your site has been submitting the old URL to Search Console for months.

The practical benefit is that search engines can make informed decisions about where to spend crawl budget. When blog content updates weekly but project pages update monthly, the sitemap structure communicates this directly. Crawlers don’t have to infer update patterns from repeated visits. They can read the structural signal.

The JSON-LD Knowledge Graph

This is where SEO architecture becomes genuinely interesting and where most implementations stop far too short.

The typical approach to structured data is page-level: add an Article schema to blog posts, maybe a Person schema to the about page, and call it done. Each page describes itself in isolation. Search engines get individual facts with no connections between them.

I built something more ambitious. The structured data layer on my site is a connected knowledge graph. Person schema connects to Organization schemas through employment relationships. Organizations connect to projects through association. Blog posts connect to their author and to subject matter through tags and categories. Academic publications carry ScholarlyArticle metadata with proper citation fields.

The result is that when a search engine reads the structured data across the site, it doesn’t just learn “this is a blog post by Blazej Mrozinski.” It learns that Blazej Mrozinski holds specific roles at specific organizations, has published specific academic work, has built specific projects, and writes about topics that connect to all of these. The site becomes a machine-readable knowledge graph that gives search engines the kind of entity understanding they need for rich results, knowledge panels, and topical authority signals.

I should be honest about the limits here. Whether Google actually uses cross-page JSON-LD relationships for ranking signals is not fully documented. Google’s own guidance focuses on per-page structured data. My reasoning is that providing richer entity connections can only help, and the worst case is that it gets ignored. I have not run a controlled test to isolate the ranking impact.

Building this during initial development was significantly easier than it would be as a retrofit. The structured data schemas were designed alongside the content schemas. Every content type was created with its JSON-LD output already defined. Adding a new page type automatically includes the correct structured data because it’s part of the template, not a bolt-on.

Here is a problem that many site builders punt on entirely: GDPR-compliant analytics. The easy path is to either ignore European privacy law (risky and irresponsible), block all analytics for European visitors (loses valuable data), or add a cookie consent banner and hope for the best.

I implemented Google Consent Mode v2, which is the proper solution to this problem. Or at least the best solution I’ve found so far. It works by conditionally loading GA4 based on user consent state. European visitors see a consent prompt. If they decline, analytics scripts don’t load and no tracking occurs. If they accept, full analytics activate. For visitors outside the EU, analytics load normally.

The key insight is that Consent Mode v2 doesn’t just block or allow analytics. It sends “consent signals” to Google that allow for cookieless measurement modeling even when users decline. The modeling fills in gaps, so you lose granularity on individual sessions, but you retain a reasonable picture of aggregate traffic patterns. This is a meaningful distinction for a new site trying to understand its audience patterns.

Some readers will object that relying on Google’s modeled data is trusting a black box. That’s fair. The alternative for a solo builder is either no European analytics at all or a privacy violation. Given those options, modeled data from a consent-compliant setup seems like the best available trade-off.

Setting this up during initial development meant the analytics configuration was correct from the first visitor. There was never a period of non-compliant tracking that might need to be cleaned up, and there was never a period of zero measurement while waiting to implement a consent solution.

Cover Images as Infrastructure

Every blog post needs an Open Graph image for social sharing. When someone shares a post on LinkedIn or Twitter, the platform pulls the og:image meta tag and displays it as a preview card. Posts without these images get generic link previews that are easy to scroll past.

Most bloggers handle this manually. They create an image in Canva or Figma for each post, export it, upload it, and reference it in their frontmatter. This works until you have 30 posts and realize that your older posts have inconsistent image styles, some posts have no image at all, and creating images has become a friction point that discourages publishing.

I built an SVG-to-PNG generation pipeline. Each blog post automatically gets a cover image rendered from a template that uses the post title, date, and category. The images are consistent in style, generated at build time, and require zero manual effort per post. The template is designed once, and every future post inherits it.

The trade-off is that generated images lack the bespoke quality of a hand-designed cover. For a personal site where publishing cadence matters more than visual branding on each individual post, I think this trade-off lands in the right place. If the site reaches a point where custom images meaningfully affect engagement, the pipeline can be extended or overridden per-post.

This is infrastructure thinking applied to what most people treat as a per-post creative task. The upfront cost was a few hours of template design and pipeline configuration. The ongoing cost is zero.

The Redirect Nobody Thinks About

When I switched from a single sitemap to a multi-sitemap architecture, the old sitemap URL needed to continue working. Search engines and any existing Search Console submissions pointed to the original URL. A 301 redirect from the old path to the new sitemap index URL ensures that nothing breaks.

This is a five-minute fix during initial development. It’s a potential indexing disruption if you do it six months after launch, after search engines have been fetching the old URL on a regular schedule. The redirect itself is trivial. The timing of when you implement it is what matters.

I mention this specifically because it’s representative of a whole class of SEO decisions that are cheap when made early and expensive when made late. Canonical URL structure, trailing slash policy, www versus non-www resolution, pagination handling. Each one is a simple decision at foundation time and a migration project after the fact.

What This Costs Versus What Retrofitting Costs

Building all of this took roughly two days of focused work during the initial site development. That includes IndexNow integration, multi-sitemap configuration, the full JSON-LD schema hierarchy, Consent Mode v2 implementation, the cover image pipeline, redirect setup, and systematic meta tag optimization for every page template.

Two days, as part of a five-day build. About 40% of the total development time went to search infrastructure.

That number sounds high until you consider the alternative. In my experience, retrofitting the same capabilities onto an existing site with 50 pages of content takes longer, requires careful testing to avoid disrupting existing indexing, and introduces risk of regression. Every structural change to an established site needs to be validated against its current search performance. A foundation-stage implementation has no existing performance to protect, which means you can move faster and experiment more freely.

The 40% investment also pays dividends that accrue automatically. Every new blog post gets correct structured data, a generated cover image, IndexNow submission, proper sitemap inclusion, and optimized meta tags without any additional per-post SEO work. The infrastructure handles it.

The Compounding Effect

The real argument for SEO architecture over SEO optimization is compounding. Every piece of content published on a properly architected site starts with structural advantages that a retrofitted site has to create manually for each piece.

Post number one benefits from IndexNow, structured data, and a proper sitemap entry. So does post number fifty. So does post number two hundred. The per-post cost of SEO infrastructure is zero after the initial build, while the per-post cost of manual optimization never goes away.

For founders and builders who know they’ll be creating content over months and years, this math is compelling. I won’t claim it’s universally decisive, because some sites may never grow past a handful of pages, and for those the upfront investment is harder to justify. But if you anticipate a sustained publishing cadence, the question is whether you spend two days now or two days repeatedly, with diminishing enthusiasm each time.

My site was indexed within hours. Every post since has followed the same pattern. When I eventually apply content strategy and keyword optimization on top of this foundation, the infrastructure is already there to maximize the impact of that strategic work. The plumbing doesn’t need to be installed while the house is full of furniture.

SEO architecture before your first visitor is not premature optimization. It’s the same principle that applies to database schema design, API versioning, or any other structural decision. If you’re interested in the broader infrastructure story, I’ve written a seven-part series on building WordPress infrastructure from scratch that covers the server and application layers underneath decisions like these. Get it right at the foundation and everything built on top benefits. Defer it, and you pay the retrofitting tax on every piece of content you’ve already published. I can’t prove the counterfactual. I can say that eight weeks in, I have not once had to go back and fix a search infrastructure problem on an already-published post. That alone has been worth the two days.