Why the analyzer wants a link to your blog or guides, a...

The Mega Analyzer row Link to a blog / resources / guides section turns red on almost every small business site I audit, and the owner's first reaction is usually "we're a plumber, why would we have a blog." Fair question. What the row measures is whether the audited page connects, in one click, to a place where the business explains things instead of selling them. A site whose only pages are Home, Services, About and Contact has nowhere for expertise to be shown rather than claimed.

What the check actually tests

The row lives in the Trust + Conversion completeness card, under the Depth + transparency heading, next to the pricing, FAQ, about and team rows. It uses the same title whether it passes or fails. On a pass the detail is empty. On a fail it reads: "Content hub (/blog/, /resources/, /guides/) is the primary E-E-A-T surface area." It renders as a hard pass or fail (a red ✗, not the blue ℹ the optional rows get), but the flag feeds no score. It is a red mark in the card, not lost points.

It is not gated by page type either. The team row two lines down softens to info-level for a local business with an About page; this one fires the same way on a home page, a service page or a checkout page.

The flag is an OR of four signals:

A link whose path contains a recognized hub segment. The analyzer collects the raw href of every <a> on the page, internal and external alike, and passes if any one contains a slash, one of these names, then another slash, the end of the string, a ? or a #: blog, article or articles, insight or insights, resources, learn, guide or guides, news, desk or desks, coverage, brief or briefs, publication or publications, stories, topic or topics, section or sections, category or categories, report or reports, wire, post or posts, essay or essays, note or notes, journal. Matching is case-insensitive.
Article-class JSON-LD anywhere in the page's structured data. BlogPosting, NewsArticle, Article, TechArticle, ScholarlyArticle, Newsletter or Periodical in the schema types passes the row without any link. The type walker descends into every nested object, so a BlogPosting listed inside a Blog's blogPost array on an index page counts the same as a top-level one on an article page.
A feed declared in the head. A <link rel="alternate" type="application/rss+xml"> (or atom+xml, or feed+json) satisfies it. One trap: the regex expects rel to appear before type inside the tag, with both values in quotes. A tag written with type first is real to browsers and invisible to this check.
A query-routed view. Any href containing ?view=, ?desk=, ?section=, ?topic=, ?category= or ?tab= (or the same after & or #) passes, because single-page publications route their sections that way.

That list explains the failures that look wrong at first sight:

The hub exists but the audited page never links to it. The analyzer reads one page. A /guides/ section that is only reachable from the About page fails on the home page.
The hub is at a path the regex does not know. /library/, /knowledge-base/, /help/, /tips/, /how-to/, /academy/, /press/ and /media/ all fail on the link branch. So do two spellings that feel like they should pass: /blogs/ (the pattern is blog, with no optional s, while articles, guides and insights do take one) and /resource/ (the pattern is the plural).
The hub link is a file, not a directory. /blog.html and /news.php fail, because a dot is not one of the four characters allowed after the segment. /blog/ passes.
The link is relative without a leading slash. href="blog/" has no slash before the word, so it fails. href="./blog/", href="/blog/" and a full URL all pass.
The link is injected by JavaScript. The analyzer parses the fetched HTML. A menu that a script builds after load contributes nothing.

And the passes that are too easy: an outbound link to somebody else's /news/ page counts, a ?tab=pricing link on a product page counts, and an article page passes on its own schema with no hub in sight. The check confirms that a content surface is reachable. It says nothing about whether the surface is any good.

Why it matters

Start with what Google tells site owners to ask about their own pages. The helpful content documentation frames it as "Who, How, and Why": is it self-evident who authored the content, does the site link to "further information about the author," and was it made "primarily to help people." Its self-assessment list includes "Does your content clearly demonstrate first-hand expertise and a depth of knowledge (for example, expertise that comes from having actually used a product or service, or visiting a place)?" A four-page brochure site cannot answer that with a yes, because nothing on it could demonstrate anything. The hub is where a byline, a date, a cited number and a first-hand account can exist at all.

The same document says "E-E-A-T itself isn't a specific ranking factor" and that rater data "is not used directly in our ranking algorithms," so the rater guidelines are not a rubric you are graded against. Google's page says reading them can "help align it conceptually with the different signals that our automated systems use to rank content," and recommends them as a way to "self-assess."

Read that way, the September 11, 2025 edition is blunt about where the evidence comes from. Section 3.3 opens with "An important part of PQ rating is understanding the reputation of the website." Section 3.4 defines Experience as "the extent to which the content creator has the necessary first-hand or life experience for the topic," Expertise as "the necessary knowledge or skill for the topic," and Authoritativeness as being "known as a go-to source for the topic." The rating table lists "Information provided by the website and content creator" as its own consideration: what sites say about themselves "isn't always trustworthy, it can provide an important starting point." An electrician who has published twelve pieces on panel upgrades, permit timelines and what a quote should itemize has shown skill in writing; the one with a Services page has asserted it.

Site-wide signals are the second reason. Google's ranking systems guide says the systems "are designed to work on the page level," then that "Site-wide signals and classifiers are also used and contribute to our understanding of pages." The helpful content system, which "became part of our core ranking systems" in March 2024, was the best-known of those. A hub is where a site accumulates pages that can each be judged helpful on their own. Without one, the site-wide view has four pages to read, and three of them are navigation.

Discovery is the third, and it is the part the row can actually see. The SEO starter guide says "Google primarily finds pages through links from other pages it already crawled," and the crawlable-links documentation adds that Google "can only crawl your link if it's an <a> HTML element" with an href, with anchor text that "tells people and Google something about the page you're linking to." A hub linked from the header of every page is linked from every page Google already has. One thing people assume that the documentation does not say: nothing official states that a navigation link outranks a footer link. A footer-only hub passes the check and is crawlable. The reason to put it in the header is that humans find it there.

The starter guide has one more line worth knowing when you pick the path. For sites with more than a few thousand URLs, "using directories (or folders) to group similar topics can help Google learn how often the URLs in individual directories change." Small sites are below that threshold, but the habit costs nothing, and a stable /guides/ directory is also what the analyzer recognizes.

For AI answer engines I can offer experience rather than a citation. In the audits I run, the pages that get quoted answer a question someone actually typed: what a service costs, how long it takes, what to check before buying. Service pages describe an offer; they rarely answer a question. The hub is where the answerable pages live, and it is the natural home for everything the analyzer's other content rows ask for: the Updated-on stamp, dateModified, the author-profile link, the 800-word depth threshold, the table of contents. The row is a proxy for all of that, which is why it is worth fixing even though it moves no score.

How to fix it

1. If you already publish, make the hub reachable from every page at a recognized path. Put it in the primary navigation and the footer with anchor text that names what is there: "Guides" or "Storage tips," not "More." The shape the analyzer wants is nothing more than this:

<nav aria-label="Primary">
  <a href="/">Home</a>
  <a href="/services/">Services</a>
  <a href="/guides/">Guides</a>
  <a href="/about/">About</a>
  <a href="/contact/">Contact</a>
</nav>

If the hub lives at /library/ or /knowledge-base/, move it to a recognized directory and redirect the old paths. On Netlify that is one line in _redirects:

/library/*  /guides/:splat  301

If renaming is off the table, serve the same index at a recognized alias path and link to that. If your hub is a single file at /blog.html, give it a directory.

2. If you have nothing yet, build a /guides/ index and three to five pieces you can write from experience. Not "industry trends." The questions customers ask before they buy, a pricing explainer with real ranges, a how-to for your service area, a comparison between the two options people always weigh, a checklist. Each piece should clear the analyzer's other content rows while you are at it (they sit in the E-E-A-T signals card and the article checks, not this one): 800 or more words, a named author with a bio page the byline links to, datePublished and dateModified in the JSON-LD, a visible Updated-on line, a first paragraph that defines the thing the title names, and a table of contents once it is long enough to need one.

Single Site Gen gets you the structure without a week of setup. It does not write files; it builds the specification prompt you hand to an AI coding agent. Keep "Blog" in its Key pages field (it is there by default) and the spec already includes blog pages with Article or BlogPosting schema, a breadcrumb <nav> with matching BreadcrumbList, bylines linking to a Person page, feed.xml plus feed.json, and the feed <link rel="alternate"> in the head of every page. A site built from it passes this row, the feed row and the dateModified row on the first run.

3. Shape it as one pillar per topic with focused pieces around it. The Pillar-Cluster Topology Audit scores a page as a pillar at 2,500 or more words with six or more H2 sections and eight or more distinct internal links, and as a cluster piece between 600 and 3,000 words. Its fix prompt for a cluster piece asks for a link back to the parent pillar in the first 150 words of body text and cross-links to three or more sibling pieces. You do not need the pillar first: write the focused pieces, then the overview that links them, then the link back from each.

4. Wire the hub into everything that lists pages. Sitemap entries for the index and every piece. An RSS or Atom feed, declared in the head with rel before type so the analyzer's feed branch sees it too:

<link rel="alternate" type="application/rss+xml" title="Guides" href="https://example.com/feed.xml">

A line in llms.txt pointing at the index. A link from each service page to the guide that answers that service's questions. And on the index page, schema that says what it is: CollectionPage is the schema.org WebPage subtype for exactly this, and Blog carries the blogPost property that names the pieces:

{
  "@context": "https://schema.org",
  "@type": "CollectionPage",
  "@id": "https://example.com/guides/#page",
  "url": "https://example.com/guides/",
  "name": "Guides",
  "mainEntity": {
    "@type": "Blog",
    "@id": "https://example.com/guides/#blog",
    "name": "Example Co. Guides",
    "publisher": { "@id": "https://example.com/#org" },
    "blogPost": [
      { "@type": "BlogPosting", "@id": "https://example.com/guides/what-a-quote-should-include/" },
      { "@type": "BlogPosting", "@id": "https://example.com/guides/pricing-explained/" }
    ]
  }
}

One honest warning: the nested BlogPosting entries in blogPost trip the schema branch on their own, so this block turns the row green even before the navigation link exists. Do not stop there. The link branch is the one that reflects what a visitor can reach; the block is here because the index is otherwise the one page on the hub with no schema at all.

5. Keep it alive, or do not start. A hub with one post from 2021 tells a reader the business stopped caring in 2021, which is worse than no hub. Pick a cadence you can hold (one piece a month is plenty) and run the Content Decay Audit each quarter to see what needs a refresh. When you update a piece, change dateModified and the visible stamp, not the publish date.

Then re-run the Mega Analyzer. The row passes the moment any link on the page hits a recognized path, so if it is still red after step 1, view source and check the href against the list above.

When to leave it alone

A site that is the publication. A news site, a newsletter archive or a magazine passes on the schema and feed branches anyway; the row was written for business sites.
A single-page site that will stay single-page. A launch page for one product, an event, a waiting list. Accept the red mark; a "Blog" link to one post does not make the page better, and the analyzer cannot tell a real hub from an empty one.
A business that cannot hold a cadence. If nobody will write the fourth piece, three pieces with an author bio and correct dates still beat none, but do not call the section "News" and let it sit. Call it "Guides," date the pieces, and leave them as the evergreen answers they are.
A hub the platform pins to an unrecognized path or host. Some hosted help centers live at help.example.com with articles at the root, and some builders fix the section at /academy/. The analyzer stays red and the site is fine. Add a recognized alias on your own domain if the platform allows it; stop there if it does not.
Gaming it. A ?tab= parameter on an internal link, or a link to some other site's /news/, flips the row green and leaves the page no better for anyone. Treat the four branches as diagnosis, not loopholes.

If you build sites for clients, the cheapest time to ship a guides section is the first build, when the index, the feed and the byline template cost an hour and the client still has five questions they are tired of answering by phone. The $20 Dollar Agency treats that hub as part of the standard deliverable rather than an upsell, because it is the only part of a small business site that keeps earning after launch.

Fact-check notes and sources

Source: https://developers.google.com/search/docs/fundamentals/creating-helpful-content establishes the "Who, How, and Why" framing, the self-assessment questions quoted above ("first-hand expertise and a depth of knowledge," "primary purpose or focus"), that "E-E-A-T itself isn't a specific ranking factor," that rater data "is not used directly in our ranking algorithms," and the recommendation to read the rater guidelines to "self-assess."
Source: https://static.googleusercontent.com/media/guidelines.raterhub.com/en//searchqualityevaluatorguidelines.pdf (General Guidelines, September 11, 2025 edition, 182 pages) establishes Section 3.3 "Reputation of the Website and Content Creators," the Section 3.4 definitions of Experience, Expertise and Authoritativeness quoted above, Trust as "the most important member at the center of the E-E-A-T family," and the "Information provided by the website and content creator" consideration with its "important starting point" caveat.
Source: https://developers.google.com/search/docs/appearance/ranking-systems-guide establishes that ranking systems "are designed to work on the page level" while "Site-wide signals and classifiers are also used," and that the helpful content system "became part of our core ranking systems" in March 2024.
Source: https://developers.google.com/search/docs/fundamentals/seo-starter-guide establishes that "Google primarily finds pages through links from other pages it already crawled," that "the vast majority of the new pages Google finds every day are through links," and the directory-grouping guidance for sites with more than a few thousand URLs.
Source: https://developers.google.com/search/docs/crawling-indexing/links-crawlable establishes that Google "can only crawl your link if it's an <a> HTML element" with an href, that ./products/... relative links are parseable, and that anchor text "tells people and Google something about the page you're linking to."
Source: https://schema.org/Blog establishes the Blog type (Thing > CreativeWork > Blog) and its blogPost property, which "Supersedes blogPosts."
Source: https://schema.org/CollectionPage establishes CollectionPage as a WebPage subtype ("Web page type: Collection page") that inherits WebPage properties such as breadcrumb and lastReviewed.
Source: the Mega Analyzer source itself (the hasBlogLink flag and the Trust + Conversion completeness row that renders it) establishes the four pass branches, the recognized segment list, the recursive JSON-LD type walker, the rel-before-type feed regex, and the fact that the flag feeds no score.

Why the analyzer wants a link to your blog or guides, and what to do if you have none