Blog and Site Architecture for SEO and Conversions in the AI Search Era

For many sites, the blog and the other resource pages are the main source of organic visibility. They bring new people to the site by answering their questions, and the value you give them that way often comes back to you: they return, they subscribe, and some of them become customers and advocates of the brand.

That was true when I first wrote about blog structure in 2021, and it’s still true now. What has changed is who is reading. Your blog is now read by people, by Googlebot, and by AI systems that break a question into dozens of sub-questions, pull a single passage out of your post, and quote it in an answer the reader may never click through from. (Looking at you, AI Overviews.)

So, does that make blog architecture less important? Well, no. It makes it more important, and a little bit different. Let me explain.

In this guide, I’ll cover:

• how AI Overviews, AI Mode, ChatGPT search and Perplexity find, retrieve and cite pages, and what that means for the way you structure your blog
• a short recap of the search intent-first framework, which should sit underneath every architecture decision
• where your blog should live: navigation, subfolder vs subdomain, and what to do with news and press releases
• the flat vs tree URL structure debate, and why click depth is the question you should actually be asking
• topical hubs, clusters and internal linking
• categories, tags, breadcrumbs, pagination and faceted archives (the unglamorous bits that quietly break things)
• blog page layout that serves both readability and conversions: summaries, tables of contents, headings, authors, CTAs and related posts
• llms.txt, with an honest caveat
• how to measure all of this in GA4 and Search Console, including AI referral traffic
• a free Python script that audits your blog’s click depth, orphan posts, category balance and hub coverage

The audit script is in the MLforSEO code hub. You can run it on your own site while you read.

How AI search finds, retrieves and cites your blog posts

Before we talk about folders and menus, it’s worth understanding what changed under the hood. I’ll keep this practical: you don’t need to become an information retrieval engineer to structure a blog well. You do need a working mental model.

Step 1: the page has to be crawlable, indexable and allowed

Every AI search product I’ll mention here still starts with a boring, old-fashioned requirement: it has to be able to fetch your page.

• Google AI Overviews and AI Mode use Google’s normal index. Google’s own documentation says that to be eligible as a supporting link, “a page must be indexed and eligible to be shown in Google Search with a snippet”, and that there are no additional technical requirements.
• ChatGPT search relies on OpenAI’s OAI-SearchBot. OpenAI’s crawler documentation is explicit that sites that opt out of OAI-SearchBot won’t be shown in ChatGPT search answers (they can still appear as plain navigational links). GPTBot, the training crawler, is a separate decision.
• Perplexity uses PerplexityBot to surface and link websites in its answers, and says it is not used to crawl content for training foundation models. A separate agent, Perplexity-User, fetches pages when a user asks for them. Both are described in Perplexity’s bot documentation.

This is where architecture starts. A post that is five clicks deep, linked only from page 9 of a paginated archive, or blocked by an over-eager robots.txt rule, isn’t going to be cited by anyone. (If you haven’t checked yours recently, read why your robots.txt might be the silent killer of your AI traffic.)

Step 2: one question becomes many (query fan-out)

When Google introduced AI Mode in March 2025, it described a “query fan-out” technique: the system issues multiple related searches at the same time, across subtopics and data sources, and then brings the results together. Google’s documentation now says both AI Overviews and AI Mode may use it.

Why should a blog owner care? Because fan-out rewards sites that cover a topic as a set of clearly separated sub-topics. If someone asks “how should I structure my company blog for SEO?”, the system might look separately for subfolder vs subdomain, category pages, internal linking, author pages and so on. A blog organised as a hub with focused spoke posts (or a long guide with clearly labelled sections) has a page or passage ready for each of those sub-queries. A blog that is “one giant jumble of information” doesn’t. I go deeper into the mechanics in how entities power query fan-out in AI search.

Step 3: retrieval happens at the passage level

This isn’t entirely new. In October 2020, Google announced passage ranking: the ability to rank a specific passage from a page, which it said would “improve 7 percent of search queries across all languages”. It’s a ranking change, not a separate index, but the principle carried over into AI search: systems look for the part of a page that answers the sub-question.

Retrieval-augmented generation (RAG) systems typically split documents into chunks before they retrieve them. Google doesn’t publish how Search chunks pages, but its enterprise search product, Vertex AI Search, documents layout-aware chunking that detects headings and lists, with an option to include the ancestor headings in each chunk. That’s a different product, so don’t read it as “this is how Google Search works”. But it shows the general pattern: headings are context. A chunk that starts under the heading “Should you include tags in your blog URLs?” carries its own meaning. A chunk that starts with “As mentioned above, this is also true here” carries none.

Now, the caveat, because I don’t want you to go and chop every post into 40-word fragments. Google’s own guide to optimising for generative AI features says, plainly, “There’s no requirement to break your content into tiny pieces for AI to better understand it,” and that optimising for generative AI search is “still SEO”. I agree with both. What I’m recommending is not a new content format. It’s the same thing good editors have always asked for: one idea per section, a heading that says what the section is about, and an answer early in the section. I’ve written more about what that looks like in the chunk, not the page.

Step 4: being cited is not the same as ranking

Here’s the bit that keeps changing. In July 2025, Ahrefs analysed 1.9 million citations from 1 million AI Overviews and found that 76% of cited pages ranked in the top 10 for the query. By its March 2026 update (863,000 keywords, 4 million AI Overview URLs), that figure had dropped to 38%, with Ahrefs attributing the change mainly to a bigger role for query fan-out (and partly to better citation parsing, so it’s not a clean like-for-like comparison). A separate Ahrefs study of 15,000 long-tail prompts found that only 12% of URLs cited by ChatGPT, Gemini, Copilot and Perplexity ranked in Google’s top 10 for the original prompt.

These are vendor studies, and the numbers move fast, so treat them as direction rather than gospel. The direction is clear, though: AI systems cite pages that rank for the sub-queries, not just for the head query. That’s an architecture argument. The more of a topic’s sub-questions your blog answers with a focused, findable page or section, the more chances you have to be retrieved. If you want to dig into why being indexed doesn’t guarantee being picked, read indexed is not selected.

Start with intent, not with folders

Every architecture conversation I’ve been part of eventually turns into a conversation about folders: what goes in the menu, what the URL should look like, whether “resources” or “blog” is the better name. Those decisions matter, but they’re downstream of a more important one: what are your visitors trying to accomplish, and what do you need them to do?

I’ve written a whole guide on this, how to build a search intent-first website architecture, so here is the short version of the framework. It’s a continuous improvement loop with five steps:

1. Define the website’s KPIs. Organic visits, new users, leads, revenue: be specific about how you’ll benchmark success.
2. Define the visitors you need to hit those KPIs, including how they search (and, now, how they prompt AI assistants).
3. Define each persona’s search intent, and what unique value you can offer compared with your search competitors.
4. Bridge the gaps between what visitors came for and the pages you need them to reach, with CTAs, internal links and navigation.
5. Evolve alongside search intent, because intent changes for pages and for whole topics.

The framework groups pages into three broad types: resource pages (blog posts, guides, glossaries) that serve informational intent and grow traffic; company pages (home, about, team, author pages) that serve navigational intent and build trust and E-E-A-T; and product pages (products, services, pricing) that serve commercial and transactional intent and convert. In an intent-driven topic cluster, the informational posts act as a support network for higher-intent pages, which in turn support a pillar page.

Your blog is the resource layer of that system. Everything in the rest of this guide (where the blog lives, how URLs and categories are organised, how a post is laid out) is in service of two jobs: getting the right informational visitor to the right post, and then giving them a natural next step towards the pages that pay the bills. If you only take one thing from this section: don’t organise your blog by what’s convenient for your CMS; organise it by what your visitors are trying to do.

Where your blog lives: navigation, location and content types

Link your blog from the main navigation and the footer

This sounds obvious, and yet I still audit company sites where the blog is reachable only from a “Resources” dropdown three levels deep, or from a footer link labelled “Insights” that nobody would ever guess.

• Main navigation: it’s the primary entry point for visitors and the most heavily linked area of the site. Linking your blog from the main menu signals that it’s a significant section, gives it a strong internal link from every page, and puts it one click from the homepage.
• Footer: a footer link makes the blog reachable from every page, including landing pages where you’ve trimmed the main menu.

While you’re in the navigation, simplify it. If there is one thing users hate, it’s feeling lost. Worse yet, wanting to find something and not being able to find a clear path to it. A few ways to reduce clutter:

• eliminate menu options that nobody uses (your analytics will tell you which ones)
• add a search bar, and actually look at what people search for in it
• group product features in a features section rather than giving each feature its own menu item
• drop the “Home” button and let the logo link back to the homepage

Subfolder or subdomain?

You have two options. You can host the blog in a subfolder (also called a subdirectory) of your main domain, such as yourwebsite.com/blog/, or on a subdomain, such as blog.yourwebsite.com.

Google’s official position is neutral. Its SEO Starter Guide says, “From a business point of view, do whatever makes sense for your business,” and back in 2018 John Mueller said that Google generally sees the two the same, adding that he’d personally “try to keep things together as much as possible.”

My take: default to a subfolder, unless there’s a genuine technical or organisational reason not to (a separate platform, a separate team, a genuinely different audience). A subfolder keeps the blog visibly part of your site, makes internal linking between posts and product pages natural, and keeps reporting simpler. A subdomain can offer more design and platform flexibility, but in my experience it tends to drift into being a separate site, with its own navigation, its own templates and very few links back to the pages that convert. That drift is the real cost, more than anything a search engine does.

Two practical tips, whichever you choose:

• Keep post URLs intuitive. The post slug should follow directly after /blog/ on a subfolder, or directly after the domain on a subdomain.
• Redirect the obvious guesses. Set up a 301 redirect so that people (and links) that go to site.com/blog reach your blog’s actual location, and vice versa.

Organise the blog as a learning centre, not a content-type archive

Many organisations organise their content by format: videos with videos, webinars with webinars, blog posts with blog posts. That’s convenient for the content team, but it’s not helpful for visitors, and it’s not helpful for search either. People look for a topic, not a format, and search engines (and AI systems) group content by what it’s about.

A learning centre approach organises content by topic and audience, and lets people filter by format if they want to. It lowers the barrier to finding the next useful piece, which tends to mean more pages per visit. Good learning centres usually have:

• filters by audience or role, and by topic
• a search bar
• sorting (newest, most popular)

Filters create URLs, though, and filter URLs can multiply very quickly. I’ll come back to how to keep them under control in the faceted archives section below.

Keep news and press releases separate

To pick up a few extra backlinks, some companies publish press releases, company news and product announcements in the blog. That can work, but if your guides and case studies are bundled with news, the least you can do is label each piece by type so visitors can navigate it.

Better still, give other content types their own sections, for example /news/ or /press/, with their own structured data where relevant. News that has nothing to do with the blog’s theme dilutes the topical focus of your blog section for readers and for search engines, and it makes your category pages (and your analytics) noisier. It also makes life easier for AI systems trying to work out what your blog is about.

Flat vs tree URL structure: to nest or not to nest?

If you’re involved in a site build, you’ll almost certainly end up in a conversation about URL structure. Ideally, a URL structure works well for users and crawlers and is easy to maintain. That is definitely possible, but it takes some strategic thinking at the planning stage. So, should you use a flat or a tree structure? To nest or not to nest? Let’s look at both, and then at the question that actually matters more.

The anatomy of a URL

Quick recap of the components, using https://www.example.com/about/team?member=kevin#experience:

Google’s URL structure guidelines recommend a simple structure, organised “in a manner that is most intelligible to humans,” using readable words rather than long ID numbers, and hyphens rather than underscores between words. A good URL:

• is short and to the point
• doesn’t repeat words
• is intuitive for both people and crawlers
• leaves out stop words (and, or, the) where they add nothing

Here’s an example of good directory usage: https://www.example.com/men/socks/tommy-hilfiger/. And here’s the same thing done badly: https://www.example.com/men-fashion/socks-for-men/tommy-hilfiger-men/. Same structure, twice the words, zero extra meaning.

One update from 2021: I used to quote a maximum URL length of around 74 characters so the URL wouldn’t be truncated in search results. I’ve dropped that rule. Search results have changed how they display URLs (since January 2025, Google no longer shows breadcrumbs on mobile results, only on desktop), so “short and readable” is the principle, not a character count.

Flat structure

A flat URL structure puts (almost) every page at the same level: yourwebsite.com/page-one/, yourwebsite.com/page-two/. Think of it as lining up all your books on a single shelf: they’re all in one place, easy to spot, and you don’t waste time hopping between folders. It’s simple to create and manage, and it’s the natural choice for smaller, less complex sites.

Pros:

• simple, short URLs that are easy to share and remember
• nothing breaks when you reorganise categories, because categories aren’t in the URL
• works well with category or pillar pages doing the organising work in the navigation, rather than in the URL

Cons:

• the URL tells nobody where the page sits, so context has to come from navigation, breadcrumbs and internal links
• as the site grows, it often leans on mega menus (large navigation panels that drop down from the main menu) to expose many pages at once; mega menus work well when they’re organised around user needs, and badly when they become a dump of every link on the site
• “flat URLs” can be mistaken for “flat architecture”, and teams forget to actually link to things

That last con is the important one. John Mueller has warned about sites where the normal navigation doesn’t let Google move between pages. In a Google Webmaster Central hangout, he said Google should be able to crawl from one URL to another “just by the links on the page”, and that if it only sees URLs through a sitemap file, it doesn’t really know how those URLs relate to each other, which “makes it really hard for us” to understand how relevant a piece of content is in the context of the site.

Tree structure

In a tree structure, the homepage sits at the root and pages are nested in folders below it: /products/men/tops/product-name/. Picture an online clothing store with a “products” folder, sub-folders for men, women and kids, and categories like tops, bottoms and accessories under each. The URL alone tells you that the page is a men’s top.

Classic tree navigation also gives every subordinate page at least four navigation links: to the previous and next page at the same level, to the parent page, and to the homepage. That’s still a useful rule of thumb for blog posts (previous/next post, category, home).

Pros:

• good organisation of information, and a clear place for every new page
• makes it easier to create pages for specific topics and to name them clearly
• scales: you can add new categories without hurting usability
• gives readers (and search engines) extra context about the page from the URL
• easy to report on in analytics, because you can filter by folder

Cons:

• needs extra navigation help for lower levels: breadcrumbs, search, and granular footer or sidebar links
• navigating a deep tree takes many interactions to get from the root to a leaf, which is harder on mobile
• the further into a tree you go, the harder it is to see where you came from
• renaming or merging a folder means redirecting every URL inside it

The real question: URL depth or click depth?

Here’s what I wish I’d emphasised more in 2021. The flat vs tree debate mixes up two different things:

• URL depth: how many folders are in the URL (/blog/post/ is 2, /guides/seo/technical/post/ is 4).
• Click depth: how many clicks it takes to reach the page from the homepage, following links.

Google cares about the second much more than the first. In 2018, John Mueller said click depth matters more than URL structure: the number of slashes in a URL doesn’t matter, but “how easy it is to actually find the content” does, and pages linked directly from the homepage are treated as more important. Google’s SEO Starter Guide adds a nuance: grouping similar topics in directories “can help Google learn how often the URLs in individual directories change.” Folders are useful for organisation and crawl patterns, not as a ranking lever.

Which means you can have a “flat” URL structure where half the posts are six clicks deep (very common on blogs with chronological pagination), and a “deep” tree URL structure where every page is two clicks from the homepage (very common on well-built ecommerce sites). The audit script in this guide reports both numbers side by side, precisely so you can spot the difference.

How to choose (and why the answer is usually “a bit of both”)

When you choose, you’re balancing a few factors:

• Size and complexity. Flat URLs are quick to set up and easy to manage for smaller sites. A tree lets bigger sites add categories without hurting usability, but it can turn into a hot mess if nobody maintains it.
• Navigation and usability. On larger sites, a tree gives visitors more context about where they are.
• SEO. Neither is inherently better for rankings. What matters is that every important page is linked, reachable in a few clicks, and placed in a clear topical context.
• Scalability. If you expect to grow, ask which structure you’ll still be happy with at ten times the size.
• Stability. Will your categories still make sense in two years? Business direction, product names and messaging change. Every category name you put in a URL is a future redirect waiting to happen.
• Brand. A clean, professional URL is part of how your site feels.

My recommendation for most company blogs: keep post URLs shallow and stable, and do the organising with links. In practice that means a pyramid: the homepage at the top, hub (pillar or category) pages in the middle, and posts at the base, all linked so that any post is within about three clicks of the homepage. The three-click rule is an unofficial design heuristic rather than a law, but it’s a handy target for an audit.

And what about putting category names in blog URLs, like /blog/seo/post-name/? It can make URLs more descriptive. It’s worth it when:

• you have a well-organised, stable taxonomy, where each category represents a real content cluster, and
• you don’t foresee major changes to that taxonomy any time soon.

Otherwise, keep categories for navigation and out of the URL. I’ll be honest: mlforseo.com itself uses category folders in its post URLs (/machine-learning-implementation-guides/onpage-seo/…). It works because the categories map to stable topics, but it does mean that when a post changes category, it needs a redirect. That’s the trade-off, made consciously.

Does URL structure matter for AI search? I haven’t seen any evidence that AI systems reward one URL pattern over another. A readable URL is a small piece of context in a citation, and that’s about it. What matters for AI retrieval is the same thing that matters for crawling: that the page can be reached, fetched and placed in context.

Parameters and fragments

URL parameters (?sort=new) and hash fragments (#section) can help visitors jump straight to a section or a filtered view. Any URL containing a # is a fragment URL, and fragments are perfect for jump links within a long post, because they point to a location on the same page without creating a new URL for search engines to crawl. Parameters, on the other hand, do create new URLs, which is why they need care on archive and filter pages (more on that below).

Topical hubs, clusters and internal linking

If click depth is the question, internal linking is the answer. And the most reliable way to organise internal linking on a blog is around topical hubs.

Pillar pages and hubs

Pillar pages are, honestly, amazing. They can become a crazy blend of a directory, a blog post and a sales page. A pillar (or hub) page covers all the main aspects of a topic on a single page, and links out to connected pages that cover each aspect in depth, which link back to the pillar.

What a hub looks like depends on the site and the business. It might be a well-written category page with an introduction and curated links, a long guide with a link-rich table of contents, or a resource library page. The important properties are:

• It’s close to the homepage (linked from the main navigation or the homepage itself).
• It links to every post in its cluster, not just the latest ten.
• Every post in the cluster links back to it, and to its closest siblings.
• It’s organised around an entity or topic, not a single keyword. That maps much better onto how AI systems break questions down. I make the full argument in the case for entity hubs over keyword landing pages.

Contextual internal links

Navigation links get a page discovered. Contextual links (the ones inside the body of a post) explain why another page is relevant. Google’s link best practices cover the basics: Google can only crawl a link if it’s an <a> element with an href attribute; anchor text should be descriptive (not “click here”); and every page you care about should be linked from at least one other page on your site.

Descriptive anchors matter even more now. The anchor text and the sentence around a link are context for readers, for search engines and for AI systems that see your page as a set of chunks. “Read more” tells nobody anything; “compare the two approaches in our guide to intent classification” does.

Three habits that make a big difference:

1. Link up, across and onward. Each post links up to its hub, across to one or two sibling posts, and onward to a relevant higher-intent page (a product page, a course, a template).
2. Link between clusters, too. Isolated clusters look tidy, but without links between them, users and crawlers can’t see how they relate to the bigger purpose of the site.
3. Update old posts when you publish new ones. New posts are born orphans. Add links to them from two or three older, well-linked posts on the same topic.

If you want to find link opportunities with data rather than gut feeling, my guide to doing an internal link audit with topic clustering walks you through it with machine learning.

Related posts

A related posts section at the end of an article is one of the quickest wins in blog architecture. It adds contextual-ish links to every post at once and gives readers an obvious next step. Two warnings: “related” plugins that match on tags alone often surface oddly unrelated posts, and a related posts block that only ever shows the newest posts does nothing for your older content. If you can, curate related posts by hand for your most important articles, and use an automated block (ideally one that matches on content similarity) for the rest.

Categories, tags and archive hygiene

This is the unglamorous part of blog architecture, and the part where I find the most problems in audits.

Categories vs tags

I love how Allyssa Barnes puts it: without categories and tags, your blog posts are “just one giant jumble of information”, like a filing cabinet with one folder containing 200 pages of paper. How is anyone supposed to find what they need? (Her original post is no longer online, but the analogy has stuck with me since 2021.)

• A category is a broad topic your blog covers. On Medium, these are the topics. If I look at my own old Medium profile, my topics would have been marketing and technology.
• A tag is a more granular, specific topic. Within marketing, I’d write about digital marketing, SEO, marketing theory and strategy. Tags add structure within a broad category.

Because they serve different purposes, you get the most out of using both. Broad categories give readers a high-level overview of what your blog covers. Specific tags help the reader who wants everything you’ve written on a narrow subject. For SEO, a clear taxonomy helps search engines understand the structure and topical focus of your content.

How many should you have? It depends on the blog, but the goal is enough structure to be useful without overwhelming people with options. My rule of thumb: one primary category per post (two at most), and a handful of specific tags, each reflecting a sub-topic the post genuinely covers.

Tag sprawl and thin archives

The most common taxonomy problem I see isn’t too few tags. It’s too many: hundreds of tags, most used once, each generating an archive page with one post on it. Those pages add crawlable URLs with almost no unique value, split your internal links across near-duplicates (“SEO tips”, “seo-tips”, “SEO Tips 2021”), and make your site look shallower to everyone.

What to do about it:

• Audit tags once a year. Merge duplicates, delete one-off tags (redirecting their archive URLs if they ever earned links or traffic), and keep a short, documented tag list.
• Decide which archives deserve to be indexed. A category page with a real introduction and a curated list of posts can be a strong hub. An auto-generated tag page with three posts usually isn’t. Many sites keep thin tag archives as noindex (or don’t create them at all) unless they add unique content.
• Turn your best category pages into hubs. Write an introduction, highlight the essential posts first, and link to everything in the category.

Breadcrumbs

A breadcrumb is a navigation aid that shows visitors where they are in the site’s hierarchy (Home › Blog › Category › Post) and lets them step back up a level. For tree structures, breadcrumbs are essential. For flat structures, they’re the main way to show a hierarchy that the URL doesn’t.

Breadcrumbs also give every post a crawlable link to its category, which keeps category hubs well linked. Google supports breadcrumb structured data, which “indicates the page’s position in the site hierarchy”. Note the January 2025 change: Google stopped showing breadcrumbs on mobile results but continues to support breadcrumb markup for desktop results. My advice: keep visible breadcrumbs for readers, and keep the markup.

Pagination

Blog archives are paginated by nature, and pagination is where chronological blogs bury their older posts. If your blog index shows ten posts per page and you’ve published 300 posts, your oldest posts are around 30 clicks deep via pagination alone. That’s why hubs and contextual links matter so much.

Google’s pagination guidance boils down to:

• link each page to the next one with normal <a href> links
• give each paginated page its own canonical URL; don’t canonicalise page 2, 3 and 4 to page 1
• don’t use URL fragments (#) for page numbers
• if you use “load more” or infinite scroll, make sure there are crawlable paginated URLs behind it

And one piece of retired advice: rel="next" and rel="prev". Google said in March 2019 that it hadn’t used them for indexing in years, and its pagination documentation now says “Google no longer uses these tags”. Other search engines may still use them, so there’s no need to rip them out, but they won’t fix a pagination problem in Google.

Faceted archives and filters

Remember the learning centre filters? Every combination of topic, audience, format and sort order can generate its own URL. On a big resource library, that can mean thousands of near-duplicate URLs, all competing for crawl attention. Google’s documentation on managing crawling of faceted navigation suggests:

• if filtered URLs don’t need to appear in search, disallow them in robots.txt
• alternatively, use URL fragments for filters, which have no impact on crawling either way
• rel="canonical" on filtered views may, over time, reduce how often they’re crawled
• return a 404 when a filter combination has no results
• use a consistent parameter order and the standard & separator

The practical rule: decide which filtered views deserve to be landing pages (perhaps “SEO guides for beginners”) and give them proper, linked, static URLs. Keep everything else out of the crawl.

Blog post layout for readability and conversions

Now let’s zoom into the post itself. The best blogs respect their readers’ time, their prior knowledge and their content preferences. Conveniently, the same layout choices that respect readers also make your content easier to retrieve and quote. Here’s what I’d put on every post template.

A clean grid and plenty of white space

One of the easiest ways to get a clean, organised design is a grid system, a technique used for decades in newspapers and magazines. A grid works at the level of units (small cells) and columns, and it gives every element a consistent place. To make it work: leave plenty of white space, reduce clutter, and design for the device most of your readers use. For most blogs that’s a phone, so design the reading experience mobile-first and keep the text column narrow enough to read comfortably on a laptop.

(In 2021 I recommended a specific grid width in pixels. I’ve dropped it: screen sizes vary too much for one number to be useful. Check your own device data in GA4 instead.)

Titles and headings that do real work

Your title is your first conversion point: it has to earn the click from the results page. Google’s title link guidance asks for descriptive, concise <title> elements and recommends making it clear which text is the main title of the page, for example by putting it in the first visible <h1>. Include the words people actually use to describe what they need, and then make it compelling: an uncommon word, a clear benefit, or an honest signal of what kind of piece it is.

About the H1: it’s the on-page equivalent of the title tag. It’s fine for the title tag (shown in results) and the H1 (shown on the page) to differ, as long as neither is misleading. Keep one clear, descriptive, concise main heading per page. (For the record, Google has said multiple H1s won’t hurt your rankings, and its Starter Guide says heading order doesn’t matter from a Search perspective. One H1 is still the cleanest choice for readers and accessibility.)

For headings, I still like the conventions from Google’s developer documentation style guide. It’s a style guide for technical writing, not a ranking document, but its rules make content easier to scan:

• write the title based on the main purpose of the document (a tutorial gets a task-based title), and each heading based on the content of its section
• don’t repeat the page title as a heading
• use sentence case, and use punctuation in headings sparingly
• if you use an abbreviation in a heading, spell it out in the paragraph that follows
• don’t put links in headings, and don’t leave headings with no content under them
• respect the hierarchy: an <h3> goes under an <h2>, and you don’t skip levels; to change how a heading looks, change its style, not its level

Self-contained sections (the AI search habit worth building)

Here’s the habit I’d add in 2026: write each section so it makes sense if it’s the only thing someone reads. Put the answer, or the main point, in the first sentence or two under the heading. Name the thing you’re talking about instead of relying on “this” and “it” from the previous section. Phrase the heading as the question or task the section answers.

Readers who arrive via a jump link benefit. So do retrieval systems that pull a single passage. And it’s simply better writing. It doesn’t mean writing in 40-word fragments (remember, Google says you don’t need to), and it doesn’t mean turning every heading into a question. It means one idea per section, signposted clearly. If you want a quick test, try the three-property sentence test in vagueness is a disqualifier.

A summary or TL;DR at the top

Long guides benefit from a short summary near the top: what the reader will learn, or the answer in three or four bullets. It helps people decide whether to keep reading, it gives skimmers the gist, and it gives your page a concise, quotable summary of its own main points. The “this guide covers” list at the top of this article is the version I use most.

Table of contents and jump links

A table of contents helps readers navigate long posts and gives every section its own fragment URL, which you can link to from other posts. Google can also show “Read more” deep links to sections of a page in its snippets. Its snippet documentation lists what makes that more likely: the content must be immediately visible (not hidden behind tabs or expandable sections), and the page shouldn’t use JavaScript to control the scroll position on load or strip the hash fragment from the URL. That’s a good reason to be careful with “accordion everything” designs on long posts.

Reading time, difficulty and content type

Tell readers the things that matter to them before they invest their time:

• How long will this take? Show an estimated reading time.
• Do I need prior knowledge? Signal the level, with words like “beginner”, “advanced”, “step-by-step” or “comprehensive” in the title, subtitle or a label.
• What kind of content is this? A single topic can be tackled as a tutorial, an opinion piece, a case study or a news item. Label the type, as well as the topic.

Hero images that earn their space

Large, non-stock hero images on blog cards and posts help connect a reader to an article before they’ve read anything beyond the title. Make sure the image is relevant to the topic and genuinely intriguing, compressed and correctly sized (heavy hero images are a common cause of slow pages), and consistent in style across the site. Give every image meaningful alt text.

Social sharing that actually works

You’ve written a brilliant, curiosity-provoking piece. A reader reaches for the share buttons, and they don’t work. This happens more often than you’d imagine, especially on company blogs where the web team is one person. Updates get pushed, mistakes happen, and a tiny bug leaves the social sharing buttons not very social at all. So: test them after every theme or plugin update. Include a “copy link” option, because a lot of sharing now happens in messaging apps and work tools like Slack rather than on public feeds.

Cards on the blog index

With dozens or hundreds of posts, how do you show as many as possible without overwhelming people? Card-based layouts are still one of the most user-friendly answers. Keep each card simple, and use image and font size to show what matters most. A good card includes:

• a featured image
• the post title
• the author (ideally with a photo)
• a short excerpt
• the publication or last-updated date
• the category or topic

Arrange cards in two or three columns on desktop, depending on your layout. Maximise how many people can see at once, without cluttering the page.

Authors and E-E-A-T

In December 2022, Google added a new “E” to its quality rater guidelines: “E-A-T is gaining an E: experience”, meaning first-hand, life experience on the topic. Its guidance on creating helpful, reliable, people-first content asks you to think about “who, how and why”, starting with: “Is it self-evident to your visitors who authored your content?”

Author information is architecture, not decoration. It’s how readers, search engines and AI systems understand who is behind your content. What I’d put in place:

• A short bio on every post. I aim for 50 to 100 words: who the author is, why they’re qualified to write this, and what first-hand experience they bring.
• A professional photo and a professional description. Something quirky is fine, but on a professional site the bio isn’t the place to lead with “mother of cats, lover of plants”.
• Links to the author’s social profiles. They confirm the author is a real, living, breathing person, and give readers a way to follow them. Trust me, both your readers and your authors will be grateful.
• An author page for each author, listing everything they’ve written. Readers who like an author will want to read more from them, and author pages are also a natural internal linking hub.
• Author markup. Use schema.org Person markup for authors, with author.name and author.url in your Article structured data as described in Google’s Article structured data documentation, and sameAs links to the author’s profiles elsewhere.

One correction to my 2021 advice. I used to recommend nofollowing the links in author bios. Don’t nofollow internal links to your own author pages: they’re exactly the links you want crawled. Reserve nofollow (or sponsored) for outbound links you don’t vouch for or were paid for.

CTAs that match the intent of the post

CTAs are how a blog turns readers into subscribers, leads and customers. They can sit in the sidebar, inline in the content or at the end of the post, and they can be text links, banners or buttons. The rule that matters most, from the intent-first framework: match the CTA to the intent of the page. A beginner’s explainer earns a newsletter sign-up, a free template or a link to a deeper guide. A comparison post earns a demo request or a pricing page link. A “buy now” banner on a beginner’s explainer mostly earns banner blindness.

A few practical guidelines:

• One primary CTA per post, repeated at most once or twice (for example, mid-post and at the end).
• Put the CTA where the reader has just got value from you, not before.
• If you have the traffic, A/B test the message by persona.
• Make CTAs real links with descriptive text, so they also work as contextual internal links.

With AI answers taking some of the clicks for informational queries, the visitors who do click through are often further along in their research. That makes a well-matched CTA on your informational posts more valuable, not less.

llms.txt: should your blog have one?

llms.txt is a proposal published in September 2024 by Jeremy Howard of Answer.AI. The idea, as llmstxt.org puts it, is to add “a /llms.txt markdown file to websites to provide LLM-friendly content”: a short Markdown file at the root of your site with a title, a one-paragraph summary and lists of links to your most important pages. For a blog, it could list your hubs and cornerstone guides.

Here’s the honest caveat: there’s very little evidence that AI search systems use it.

• Google’s guide to optimising for generative AI features says you don’t need to create new machine-readable files, “AI text files”, markup or Markdown to appear in Google Search, because “Google Search itself doesn’t use them”. John Mueller has compared llms.txt to the keywords meta tag.
• None of the crawler documentation from OpenAI, Anthropic or Perplexity says their crawlers fetch or honour llms.txt. (Some of those companies publish llms.txt files for their own developer docs, which is not the same thing.)
• An Ahrefs study of 137,210 domains in May 2026 found that 28% published an llms.txt file, and that 97% of those files received zero traffic that month; AI retrieval bots made up just 1.1% of the fetches. A smaller server-log study by EZY Research (83 sites, April to July 2026) found OpenAI, Anthropic, Perplexity and Google bots requested robots.txt hundreds of times more often than llms.txt. Both are vendor studies with their own limitations, but they point the same way.
• On the other side, Chrome’s Lighthouse now has an “agentic browsing” check for llms.txt. It only flags server errors when fetching the file, and treats a missing file as not applicable because “providing the file is optional at the moment.”

My take: an llms.txt file is cheap, harmless (Google’s guide says it will “neither harm nor help” your visibility), and might become useful for AI agents that are already on your site and looking for a map. If you have a documentation-style site or a large resource library, go ahead and add one. Just don’t expect it to change your AI visibility, and don’t let it distract you from the things that demonstrably do: crawl access, click depth, clear hubs and well-structured posts. Your robots.txt matters far more than your llms.txt.

Measuring blog architecture: GA4, Search Console and AI referrals

Architecture changes are only as good as your ability to tell whether they worked. Here’s the measurement setup I’d use in 2026.

GA4: engagement and key events

In 2021, I’d have told you to measure a better blog layout by a lower bounce rate and a longer average session duration. Universal Analytics is gone, and GA4 measures things differently:

• Engagement rate is the main engagement metric (bounce rate in GA4 is simply its inverse), alongside average engagement time and views per session.
• Key events are what GA4 now calls the actions that matter to your business (previously “conversions”). Google’s help centre explains the rename to key events. Mark your blog’s real outcomes as key events: newsletter sign-ups, template downloads, demo requests, clicks on product CTAs.
• Landing page reports filtered to your blog folder (another reason a consistent URL pattern is handy) show which posts bring people in, and which ones lead to key events.

GA4: an AI assistants channel

By default, visits from ChatGPT, Perplexity, Gemini and similar tools land in the “Referral” channel, mixed in with everything else. Google’s documentation on custom channel groups includes an official “AI assistants” example: create a new channel with a “matches regex” condition on the source, and move it above “Referral” so it’s evaluated first.

Google’s example regex is very broad (it matches any source containing “ai”, which catches things like “mail”), so I’d use a tighter pattern on Session source, something like:

chatgpt\.com|openai\.com|perplexity\.ai|gemini\.google\.com|copilot\.microsoft\.com|claude\.ai

Extend it as new assistants appear in your referral reports. ChatGPT adds utm_source=chatgpt.com to many of its outbound links, which helps, but not every AI-driven visit carries a referrer: a lot of it shows up as direct traffic. I explain how much and why in dark AI traffic.

Search Console: AI features and the performance report

Search Console is still the best view of how Google finds your blog:

• Performance report. Google says appearances in AI Overviews and AI Mode are included in the overall search traffic, reported in the Performance report under the “Web” search type. Filter by your blog folder, and look at impressions and clicks separately: as AI answers satisfy more informational queries, impressions can grow while clicks stay flat.
• Generative AI performance reports. In June 2026, Google introduced dedicated reports for its generative AI features, rolled out to all sites by the end of August 2026. They show impressions, pages, countries, devices and dates (not clicks), and the data continues to be included in the overall performance report. Use them to see which posts and hubs are being surfaced in AI features.
• Page indexing report. Watch for “Discovered, currently not indexed” and “Crawled, currently not indexed” on blog URLs. Clusters of these often point to thin archives or posts that are too deep.

And for AI visibility beyond Google, a classic rank tracker won’t tell you the whole story. I explain why, and what to use instead, in your rank tracker is lying to you about AI search.

Audit your blog architecture with Python

To make all of this actionable, I’ve written a small Python script that audits a blog’s architecture. You can grab it from the MLforSEO code hub. It works in two modes:

• From a sitemap: it reads your XML sitemap (including sitemap indexes), then crawls your site politely from the homepage, following normal links.
• From a Screaming Frog crawl: export the Internal tab (HTML) and, optionally, the All Inlinks bulk export, and the script does the analysis without crawling anything.

# install the requirements
pip install -r requirements.txt

# mode A: from your sitemap (crawls politely, 0.5s between requests)
python blog_architecture_audit.py --sitemap https://www.example.com/sitemap_index.xml

# mode B: from a Screaming Frog export (+ sitemap to find orphans)
python blog_architecture_audit.py --sf-internal internal_html.csv \
    --sf-inlinks all_inlinks.csv --sitemap https://www.example.com/sitemap.xml

It answers five questions and writes each answer to a CSV, plus a readable summary:

1. Click depth: how many clicks from the homepage is each page, and which ones are deeper than three?
2. URL depth vs click depth: which pages look shallow in their URL but are buried in your links?
3. Orphans: which sitemap URLs have no internal links pointing to them, and which posts have at most one contextual (in-content) link?
4. Category balance: how many posts sit in each section, which sections are thin, and which dominate?
5. Hub coverage: does each hub or category page link to all the posts that live under it, or only the latest few?

The core of the hub coverage check is only a few lines: for every hub, take the URLs that live in its folder, and check which of them the hub (or its paginated pages) actually links to.

for h in hubs:
    kids = [k for k in by_parent.get(h, []) if not is_pagination(k)]
    hub_family = {h} | {u for u in outlinks if u.startswith(h) and is_pagination(u)}
    linked = {k for k in kids if any(k in outlinks.get(src, ()) for src in hub_family)}
    coverage = len(linked) / len(kids)

Your blog architecture checklist

Here’s everything from this guide as a checklist you can work through:

1. Start from intent. Define KPIs, personas and intents before you design folders and menus.
2. Link your blog from the main navigation and the footer.
3. Host the blog in a subfolder unless you have a strong reason not to, and redirect the obvious guesses (/blog).
4. Organise by topic and audience, not by content format, and keep news and press releases in their own section.
5. Keep post URLs short, readable and stable. Only put categories in URLs if your taxonomy is stable.
6. Measure click depth, not just URL depth. Aim for every important post within about three clicks of the homepage.
7. Build hubs that link to every post in their cluster, and make every post link back up, across and onward.
8. Use descriptive anchor text and update old posts to link to new ones.
9. Keep your taxonomy tidy: one primary category per post, a handful of tags, no tag sprawl, and a decision about which archives are indexed.
10. Use breadcrumbs (visible and marked up), crawlable pagination with self-referencing canonicals, and controlled faceted URLs.
11. Write self-contained sections with descriptive headings and the answer up front, plus a summary and a table of contents on long posts.
12. Show reading time, level and content type.
13. Make authors visible: bios, photos, social links, author pages and Person markup.
14. Match CTAs to the post’s intent, and add curated related posts.
15. Check crawler access for Googlebot, OAI-SearchBot and PerplexityBot before you worry about llms.txt.
16. Measure: GA4 key events and an AI assistants channel, Search Console performance and generative AI reports, and a regular architecture audit.

Implementing these changes is likely to lead to more conversions and more traffic. At the very least, it will lead to a better reader experience, and in 2026 that reader might be a person or a machine. Let me know what changes you see after you implement them.

Further reading

A few resources that shaped my thinking on this topic, then and now:

• My deep dive on the planning side: How to build a search intent-first website architecture, with a free intent mismatch audit notebook.
• Google’s own summary of what does and doesn’t matter: Optimizing your website for generative AI features on Google Search.
• Christine Austin’s article on blog layout best practices for IMPACT, which inspired parts of my original layout guide.
• Nielsen Norman Group on why mega menus work well (when they’re done right).
• Search Engine Journal on the pyramid site structure.

Related glossary terms

• AI Overview
• Search Intent
• Query Path
• Entity
• Topic Modeling