Before Anyone Can Find You: The SEO Infrastructure Behind This Site

The Build Isn’t Done When the Site Looks Good

There’s a version of this story where I build a good-looking site, push it to Vercel, and call it done. The pages load. The nav works. The blog renders. Ship it.

But a site that looks good and a site that gets found are two different things. The infrastructure underneath: the signals you send to Google, the metadata you attach to every page, the file that tells search engines what exists — none of that is visible on the page. And none of it gets set up automatically.

This post is about that layer. The part that lives in the <head> tag, in your Google accounts, and in a few XML files most people never look at. I’ll explain what each piece is, why it matters, and how I used Claude Code to build it without writing any of it by hand.

What I Actually Prompted

Here’s the honest starting point. I didn’t sit down and research SEO infrastructure and then write code. I described what I wanted in plain language:

“I want this site to show up in Google search results. I want to be able to see who’s visiting and which pages they’re reading. And when someone shares a link to this site on LinkedIn or anywhere else, I want it to look professional, not like a raw URL.”

That was roughly the prompt. Claude then asked clarifying questions, explained the pieces involved, and implemented all of it. But understanding what it built and why is the part that makes you better at building the next thing. So let’s peel back what’s actually going on.

Google Analytics 4: Your Eyes Inside the Site

Google Analytics 4 (GA4) is a free tool from Google that tracks what’s happening on your site. Every page view, every session, where visitors came from, which pages they read, how long they stayed.

Without it, your site is a black box. You push content. You have no idea if anyone sees it.

Here’s what Claude actually added to make this work. Inside the <head> tag of every page, there’s this:

<script async src="https://www.googletagmanager.com/gtag/js?id=G-GFMT94VDS4"></script>
<script>
  window.dataLayer = window.dataLayer || [];
  function gtag(){dataLayer.push(arguments);}
  gtag('js', new Date());
  gtag('config', 'G-GFMT94VDS4');
</script>

That’s two JavaScript snippets. The first loads Google’s tracking library from Google’s servers. The second initializes it with this site’s unique tracking ID (G-GFMT94VDS4) and fires an event every time someone loads a page.

Because this site is built with Astro and uses a shared layout (BaseLayout.astro) that wraps every single page, adding this to that one file means it runs everywhere automatically. One edit, site-wide coverage. That’s the architectural payoff of having a proper layout system.

The data flows into the GA4 dashboard in real time. You can open Reports, go to Realtime, load your own site in another tab, and watch yourself show up as an active user within about thirty seconds.

Google Search Console: Your Relationship With Google

GA4 tells you what happens after people arrive. Google Search Console tells you what happens before: how Google sees your site, what it’s indexing, and what search queries are driving impressions and clicks.

Before Google will show you any of that data, it needs to verify that you actually own the site. There are a few ways to do this. The method Claude set up was an HTML file verification.

Google gives you a unique filename — something like googlea43aac68075069b9.html — and a specific string of text to put inside it. You place that file in your site’s public/ folder (which in Astro maps directly to the root of your deployed site), push it to GitHub, and once Vercel deploys it, Google can confirm the file is there. Ownership verified.

One thing I learned the hard way: the file needs to actually be deployed before Search Console can verify it. I ran into a failed verification early on because I hadn’t pushed the commit that contained the file. The build was sitting locally on my machine, not live on the server. Once I pushed, verified, and navigated to Search Console, it worked immediately.

The Sitemap: Telling Google What Exists

Verification proves ownership. But Google still has to discover your pages. Left to its own devices, it finds pages by following links, starting from your homepage, crawling to every page linked from there, and so on.

That works for your main pages. It’s slower and less reliable for deeper content: glossary terms, blog posts, project pages. You might wait weeks for all of them to surface.

A sitemap solves this. It’s an XML file that lists every URL on your site, explicitly. Think of it as handing Google a table of contents instead of making it explore room by room.

Astro generates this automatically through a package called @astrojs/sitemap. Add it to your Astro config, point it at your domain, and it builds the sitemap file during every build time. No manual maintenance required.

This site’s sitemap lives at /sitemap-index.xml. That index file points to /sitemap-0.xml, which currently lists 79 pages: the homepage, 8 blog posts, 64 glossary terms, the manifesto, and 2 project pages. Once you submit the sitemap URL inside Search Console under the Sitemaps section, Google will crawl every page in that list.

Indexing takes time. For a new site, expect days to weeks. But submitting the sitemap gives you visibility into the process. Search Console will show you which pages are indexed, which are pending, and which it skipped and why. That feedback loop doesn’t exist without it.

The Favicon: A Small Signal That Carries Weight

A favicon is the small icon that appears in your browser tab, in bookmarks, and when someone saves your site to their phone’s home screen. On this site, it’s the glowing lightbulb from the TWO brand mark.

Technically it’s a single line in the <head>:

<link rel="icon" type="image/png" href="/favicon.png" />

But getting there took a few iterations. The original favicon was a crop from a wider image. It looked fuzzy and off-center at small sizes, which is exactly what a favicon is always displayed at.

For this session, we replaced the logo with a new version of The Wise Operator mark that has the trademark symbol built directly into the image. Then Claude wrote a short Node.js script using a library called sharp to identify the exact pixel bounds of the lightbulb, crop tightly around it, convert the white background to the site’s dark color, and scale it down to 64x64 pixels.

Why does this matter? Because at 16px or 32px in a browser tab, a poorly cropped image looks like a smudge. A tight, well-centered crop reads as an icon. Small details compound. Every time someone has this site open in a tab, that favicon is doing quiet brand work.

Open Graph Tags: How Your Site Looks When Shared

When someone pastes a link on LinkedIn, Slack, iMessage, or Twitter, the platform doesn’t just show a raw URL. It fetches a preview: a title, a description, and an image. That preview is controlled by Open Graph tags, a set of metadata in the <head> of each page.

Here’s what’s in the <head> on this site:

<meta property="og:type" content="website" />
<meta property="og:url" content="https://scottkrukowski.com/" />
<meta property="og:title" content="Scott Krukowski" />
<meta property="og:description" content="..." />
<meta property="og:image" content="https://scottkrukowski.com/og-default.png" />
<meta property="og:image:width" content="1200" />
<meta property="og:image:height" content="630" />

And a matching set for Twitter (which has its own slightly different format):

<meta name="twitter:card" content="summary_large_image" />
<meta name="twitter:title" content="Scott Krukowski" />
<meta name="twitter:description" content="..." />
<meta name="twitter:image" content="https://scottkrukowski.com/og-default.png" />

The og-default.png is a 1536x1024 image — The Wise Operator logo centered on a dark background with the domain name underneath. This is what appears when someone shares the homepage.

For blog posts, the og:type switches from website to article, and in a future iteration each post will get its own OG image rather than the default. For now, every share renders the brand image cleanly instead of a blank preview or a random cropped screenshot.

Claude handled all of this dynamically. Because the OG title, description, URL, and image are all props passed into the base layout, they update automatically for every page. The blog layout passes article={true}. Every page passes its own title and description. The URL is computed from Astro.site plus the current page path. One template, correct metadata on every page.

Structured Data: Talking Directly to Google

There’s one more layer worth knowing about: structured data. This site includes a JSON-LD schema block on every non-article page:

{
  "@type": "Person",
  "name": "Scott Krukowski",
  "url": "https://scottkrukowski.com",
  "jobTitle": "Builder & Business Development Professional",
  ...
}

This isn’t visible to users. It’s metadata formatted specifically for search engines — a machine-readable description of who this site is about and what it represents. It helps Google understand context beyond just keywords. For a personal brand site, a Person schema is the right starting point.

How It All Fits Together

Here’s the full picture of what’s now in place and why each piece matters:

Layer	Tool	What It Does
Tracking	GA4	Records every visit and page view
Discovery	Search Console + Sitemap	Tells Google every page exists
Ownership	Verification file	Proves you control the domain
Shareability	OG tags	Controls link preview on every platform
Brand signal	Favicon	Identifies the site in tabs and bookmarks
Context	Structured data	Helps Google understand who the site is about

None of these are optional if the goal is to be found and to look credible when shared. They’re the baseline. The content layer, the blog posts, the glossary, the project case studies, sits on top of this infrastructure. Without it, even good content has no way to surface.

What Comes Next

The infrastructure is in place. Now the work is filling it. Search Console will start showing impressions as Google indexes the pages. GA4 will start showing traffic as people find and share the site. The OG image will appear every time a link gets pasted somewhere.

The next phase is distribution: getting the first few external links pointing here, which signals to Google that this content is worth ranking. That starts with LinkedIn, sharing posts that link back, and building the kind of content that people actually link to.

But none of that works without this foundation. This is the floor you build on.

Jesus told a parable about two builders: one on rock, one on sand (Matthew 7:24-27). The house on sand looked the same as the house on rock until the storm came. SEO infrastructure is like that. A site without it looks fine until you ask why nobody can find it. The unseen foundation is the one that holds.

Want to understand the terms used in this post? Check out The Vibe-Coder’s Dictionary, a growing glossary built for non-technical builders who want to understand what’s actually happening under the hood.