Setting up a gaming blog for SEO: structure, tags and tracking before content

The unglamorous part nobody shows off: structure, tags, branding, tracking and schema, all set up before the first post went live, and the reasoning behind each call.

Share
Setting up a gaming blog for SEO: structure, tags and tracking before content

Before any of the fun content, there's the unglamorous part: structure, tags, branding, tracking. None of it ranks anything by itself, but getting it wrong early means redoing it later, once you already have posts. So I did the foundation first. Here's each call, and the reasoning (with sources) behind it.

The blog in question. It’s Crit Pick, and it’s being built in the open as SeeIndie’s public SEO case study. Every post in this log documents a decision you can go and check on the live site.

This is the first post in the build-in-public log for the case study blog, and also the start of something I've wanted to do for a long time. The blog has a job: to test the thing SeeIndie keeps arguing, that a well-built website can get found in a crowded niche. But it's also a long-term dream of mine that I actually want to build out and grow. I'd rather do that in the open and take you along than tinker quietly and reveal a finished thing later. So expect the wins and the awkward bits both.

The games I started with

The first idea was simple: build around my three main games, Guild Wars 2, RimWorld, and FFXIV.

I picked them partly for the SEO reasons. Deep mechanics, strong long-tail search demand, the conditions you want if you're trying to show keyword targeting at scale. But it also helps that I actually play them. It's hard to write a guide that holds up for a game you don't know, and easy to spot where the existing guides are thin once you've put the hours in.

GW2 came first, and that was partly a design decision. I used those first pages as a testbed for the CSS, to get the look and the layout right on real content before rolling it out across the site. Design is another one of those things that's painful to change once it's everywhere, so the order was deliberate: nail the look on a small set of pages, then bring the structure in on top once there was nothing left to fiddle with. Build the design once, build the structure once, and you're not redoing either later.

Then GW3 got announced

While I was setting up the Guild Wars 2 pages, Guild Wars 3 got announced.

I half saw it coming, so it wasn't a disaster. What it did do was push me to think harder about the long-term build. Up to that point I'd been focused on getting one game's pages right. Bringing in the structure was already the next step on the plan, but the announcement made me do it more carefully, and with a brand-new game to fold in: how games cluster, how new ones slot in, how the navigation holds up when there are five games instead of two.

A freshly announced game also means new search interest with very little competition yet, which is rare in an established niche. So I built the GW3 pages and decided to lead with those. The takeaway I'm keeping: don't get so attached to a plan that one announcement breaks it. Build the structure flexible enough that a new focus slots in, instead of forcing a rebuild.

Structure first, because it's the expensive thing to change

I worked out the navigation before writing much, aiming for something that still makes sense once there are five games on the site instead of two. The top level looks like this:

  • Games (a dropdown, with the games and their sections inside)
    • Guild Wars 2 → GW2 Quizzes
    • Upcoming → Guild Wars 3
  • About
  • Quizzes
  • Contact

One note on that dropdown. Ghost's built-in navigation is flat, it doesn't do nested menus. So the “Games” dropdown is custom, built with code injection. A bit of extra work up front, but it's what lets the menu group games cleanly and grow without turning into a flat list of twenty links. RimWorld and FFXIV slot straight in under “Games” when their pages are ready, no rebuild needed.

The other choice was to give indie games their own section even though they're not the SEO showpiece. That's the passion corner, and I wanted a home for it from the start rather than bolting it on later.

Leading with hard keywords, and the honest catch

I'm starting with big games on purpose, and I want to be upfront that this cuts against the usual advice.

The conventional wisdom for a brand-new site is to chase low-competition, long-tail keywords first, because new sites almost never rank for the big terms quickly. The data backs that up. Ahrefs looked at roughly a million pages and found only about 1.7% of brand-new pages reach the top 10 within a year. Most pages up there are old: around 73% of top-10 results are more than three years old, and the average number-one page is about five years old.

1.7%
of new pages reach the top 10 within a year
73%
of top-10 results are 3+ years old
~5 yrs
average age of a #1 page

Ahrefs, study of roughly one million pages.

That squares with my day job. I do SEO on finance sites full-time, and even with everything dialled in, the competitive money terms are a slow climb, while a lot of the early movement comes from oddly specific long-tail queries. On one investment site I took on I got 14 keywords onto page one and 120-plus more into the top 20 in about eight weeks, and some of those were genuinely difficult, competitive terms, not just easy long-tail. The very hardest heads are still a slower game, but solid execution can move real terms faster than the averages suggest. I'm expecting the same shape here.

So why lead with hard keywords anyway? Because the whole point of this blog is to demonstrate that a well-built site can break into a saturated niche. Picking easy wins wouldn't prove much. The realistic read is that the head terms (“Guild Wars 2 builds” and the like) are a long bet, while the near-term wins come from the long-tail variations inside each cluster, the very specific questions a comprehensive page naturally starts ranking for first. I'm betting on the hard terms with eyes open, not expecting fast results.

The GW3 page: one evergreen hub vs a pile of news posts

For an unreleased game I went with a single “everything we know” page instead of a separate post for every scrap of news. Here's the thinking on both sides.

The case for the evergreen hub: before a game is out, news comes in slow and often small. A leaked feature here, a dev interview there. If I spun each one into its own post, most would be thin, and several would end up competing for the same search, so they'd split signals instead of stacking them. Consolidation tends to win here. In one content-consolidation test by Inflow, merging two competing pages into one lifted clicks per day by about 70% and impressions by about 92%. One page that I keep updating stays current by definition, collects all that interest in a single URL, and becomes the thing people bookmark and link to. It's also the lowest-maintenance option, which matters to me.

This matches what I keep running into in my own work: one genuinely good page tends to beat three thin ones that each cover a slice of the same topic. Splitting a topic up feels productive, but it usually just spreads your signals thin.

There's an AI angle too, and it points the same way. Google's own AI guidance describes a “query fan-out”, where AI Overviews and AI Mode run several related searches behind the scenes to build an answer. A page that covers a topic in depth and answers the side-questions is more likely to get pulled into that than a thin one-note post. A good hub is exactly that kind of page.

The case for lots of news posts: individual posts capture freshness better, and they can rank for very specific, timely queries that a broad page might miss. Each announcement gives you a fresh URL to share the moment it drops, so more entry points. Posts also preserve a timeline, where an evergreen page that's constantly rewritten quietly loses its own history. One real caution on the freshness front: updating just the date doesn't help. Google's John Mueller has said plainly that changing a date without changing the content is noise, and Search Engine Land's guide to byline dates walks through how Google actually treats them.

Why the hub wins for GW3 right now: pre-release, the dominant thing people search for is the summary, “what do we actually know.” One strong page answers that and keeps compounding as I add to it. While news is still a trickle, the thin-content and split-signal risks of many small posts outweigh the freshness upside.

That balance will shift later. Once release gets closer and the big reveals land, some of those will be worth a full standalone post on their own. When that happens, those posts get written and then linked from the “everything we know” page, so the hub stays the center and the posts feed into it. Hub and spokes, not one or the other.

Connecting the two clusters

GW2 and GW3 are separate topic clusters, but I link them to each other on purpose. They're their own worlds, and also obviously related, so the internal links reflect that.

The topic-cluster idea (a central pillar page plus supporting posts, all interlinked) got popular through a HubSpot writeup back in 2017. Worth a caveat, though: the eye-catching numbers you'll see quoted for it elsewhere (a domain authority jump from 49 to 60, “+500% clicks”) don't actually appear in HubSpot's original material. Other blogs added those along the way. HubSpot's own reported result was more modest, and they admit they redesigned the whole blog at the same time, so it's genuinely hard to say what caused what. I like the model as a way to organize a site, I just don't trust the hype numbers.

Internal linking itself is on firmer ground. Mueller has called it one of the biggest things you can do to tell Google which pages matter. There's a limit, though. Zyppy studied 23 million internal links and found pages with around 40 to 44 internal links pointing at them pulled in roughly four times the clicks of pages with fewer than five, but past about 45 to 50, the effect reversed and traffic started dropping. So more isn't automatically better. I'm keeping links intentional rather than wiring everything to everything.

In my own experience the clustering genuinely helps, but I want to be honest about what it isn't: a shortcut. It makes a site easier to understand, for readers and for search engines both, and it gives related pages a way to lift each other. What it doesn't do is make ranking fast or easy.

Clustering helps. It's not a magic trick that skips the line, just a lot of patient work that takes months.

I plan these clusters in an Obsidian mindmap. At first I had the Guild Wars games on separate arms, then merged them into one “Guild Wars cluster” so I'd stop treating them as unrelated. Obvious in hindsight, easy to lose track of when you're heads-down on one game :)

One mismatch I'm tracking honestly: in the mindmap, GW3 moved off the “upcoming games” arm and into the Guild Wars cluster. But on the live site, the main GW3 page still carries the upcoming tag, so it shows up in the upcoming-games area too. There's no guild wars tag yet, so right now the two are joined only through internal links. Small thing, but the kind of detail that quietly drifts if you don't write it down.

The tag system

Tags do the structural work behind the scenes, and they're not just for filing. GW3 posts and pages get the gw3 tag, GW2 ones get gw2. That's also what powers the overview pages: the Guild Wars 2 area pulls in the newest posts tagged gw2, the quizzes overview pulls everything tagged for quizzes, and so on. So tagging a post correctly is what slots it into the right overviews automatically.

There's a trap here worth flagging. Auto-generated tag pages can turn into thin, near-duplicate archive pages, which is why tools like Yoast default to noindexing taxonomy pages that don't add real value. The classic bad example is a tag page with a single post on it. So the rule I'm following: only let a tag page get indexed if it's a real topic with enough posts to be useful (the per-game ones), and keep thin or utility tags out of the index.

This matters extra on Ghost, because Ghost does not noindex tag pages by default and has no native per-tag toggle for it. To keep a thin tag out of Google you have to handle it yourself in the theme or via code injection. So the plan is workable, it just isn't automatic.

Branding, which is not original on purpose

I set up the CSS for the look: dark background, a yellow/gold accent, and a crosshair as the mark. None of it is wildly original, and I'm fine with that. It doesn't need to be clever, it needs to be recognizable.

Branding doesn't move rankings directly. But being recognizable helps people remember where they read something, and that compounds over time. So I treated it as worth doing early, just without over-thinking it.

Tracking, set up before publishing anything

I wired up three tools before the first post went live, so there's a baseline from day one. They're complementary, and each one is blind to what the others see, so it's worth knowing what each does and doesn't tell you.

ToolWhat it showsWhat it's blind to
Google Search Console Google's own search data, the closest thing to ground truth for what's happening in search. Capped at 1,000 rows, 16 months, rare long-tail dropped, so totals never fully add up (workarounds). Google-only, no Bing.
Microsoft Clarity Free heatmaps and session recordings, so you see what people actually do on a page. Recordings are DOM reconstructions, not real video, so dynamic bits don't always replay. Nothing about rankings or how people found you.
Semrush Keyword research and rank tracking. Volumes are modeled estimates, not real numbers. I treat them as directional and cross-check clicks in GSC.

The split-tool habit comes straight from the day job. I've learned to trust GSC's real clicks over any tool's estimated volume, Semrush included, I treat those as a planning aid, not gospel. And Clarity has caught me out more than once, showing people getting stuck on something I'd assumed was obvious.

The Semrush keyword work is still in full swing and big enough that it's getting its own post rather than a paragraph here.

Schema

Ghost already adds basic structured data (Article markup) to every page, so the baseline is handled and I only expand on it where it helps. But it's worth being clear-eyed about what schema does, because it gets oversold.

Schema is just markup that tells search engines what a page actually is. It is not a ranking factor. Google says this directly: structured data makes a page eligible for rich results, it doesn't make it rank higher. Where it can pay off is click-through. Google's own docs cite Rotten Tomatoes seeing about a 25% higher click-through rate on pages with structured data, so the win is more clicks on a given ranking, not a better ranking.

Heads-up, this one changed: Google fully dropped FAQ rich results in May 2026. Adding FAQ markup no longer gets you those expandable Q&A snippets under your listing. The markup is still valid and Google still reads it, it just doesn't earn extra search-results space anymore, so I'm not building around it.

For AI search specifically, Google says there's no special schema you need to add to show up in AI Overviews or AI Mode. What seems to actually help is plain, clear content that answers a question directly and in full. Beyond that, make sure any schema you do use matches the visible text on the page, since mismatches can earn a manual penalty.

AI citations also aren't just a function of ranking number one anymore. Ahrefs found that only about 38% of pages cited in AI Overviews still rank in the top 10 for that query, down from 76% a year earlier. One caveat I'd add, in the spirit of not taking a number at face value: Ahrefs says part of that drop is its own improved citation detection, not purely a real-world shift, so I read it as a direction rather than a hard figure. Either way, plenty of those citations come from further down the results, or from pages that don't classically rank at all. The practical move is the same: write genuinely useful, extractable content rather than chase markup tricks.

So why keep schema in place at all, if it doesn't rank you and one of its headline features just vanished? Long-term insurance. Search features come and go (FAQ snippets are only the latest to go), and the ones that show up next tend to reward sites that already have clean structured data sitting there. I've had to bolt schema onto big, established sites after the fact in client work, and it's exactly the slog you'd imagine, hundreds of pages, one template at a time. I'd rather be eligible automatically than scramble to catch up. Since Ghost adds the Article baseline for free, keeping it tidy from day one costs me almost nothing and keeps the door open.

What's next

The keyword research post is coming, then the content itself starts going up. GW3 first, with RimWorld and FFXIV behind it. The interesting numbers won't show for months, so for now the value is in documenting the decisions while they're fresh. More once there's data worth looking at.


Sources

Common questions

Why set up structure and tracking before writing any posts?
None of it ranks anything by itself, but getting it wrong early means redoing it later, once you already have posts. Structure is the expensive thing to change, so it goes first.
Should a brand-new site really go after hard keywords?
Usually not. Ahrefs looked at roughly a million pages and found only about 1.7% of brand-new pages reach the top 10 within a year, and around 73% of top-10 results are more than three years old. I'm doing it anyway because the whole point of this blog is to demonstrate that a well-built site can break into a saturated niche, and picking easy wins wouldn't prove much. The near-term wins still come from the long-tail variations inside each cluster.
One evergreen hub, or a separate post for every piece of news?
For an unreleased game, the hub. Pre-release news comes in slow and often small, so separate posts would be thin and several would end up competing for the same search. Consolidation tends to win: in one content-consolidation test by Inflow, merging two competing pages into one lifted clicks per day by about 70%. Once the big reveals land, those get their own posts and link back to the hub. Hub and spokes, not one or the other.
Does Ghost noindex thin tag pages automatically?
No. Ghost does not noindex tag pages by default and has no native per-tag toggle for it, so you have to handle it yourself in the theme or via code injection. The rule I follow: only let a tag page get indexed if it's a real topic with enough posts to be useful, and keep thin or utility tags out of the index.
Is schema a ranking factor?
No. Google says this directly: structured data makes a page eligible for rich results, it doesn't make it rank higher. Where it can pay off is click-through, and Google's own docs cite Rotten Tomatoes seeing about a 25% higher click-through rate on pages with structured data. I keep it clean anyway as long-term insurance, and since Ghost adds the Article baseline for free, that costs me almost nothing.