Add FAQPage schema + answer-first intro to AI infrastructure tools guide

content/blog/ai-infrastructure-tools/index.md

@@ -13,13 +13,14 @@ tags:
     - devops
     - announcements
 category: general
+faq_schema: true
 ---
 
-The phrase "AI infrastructure" now means two different things. One is the GPUs, schedulers, and MLOps platforms that exist to run AI workloads. The other is AI that runs infrastructure: agents and assistants that generate, deploy, and govern cloud resources on your behalf. They're different markets with different vendors, and most teams need to think about both.
+"AI infrastructure tools" covers two distinct markets: infrastructure *for* AI (GPU clouds like CoreWeave, MLOps platforms like Weights & Biases) and AI *for* infrastructure (agentic platforms like Pulumi Neo that generate, deploy, and govern cloud resources for you). Most teams need tools from both categories, and picking the wrong one wastes budget and adoption goodwill.
 
 <!--more-->
 
-The pressure to think about both is real. [McKinsey research](https://www.mckinsey.com/capabilities/mckinsey-digital/our-insights/the-economic-potential-of-generative-ai-the-next-productivity-frontier) puts the productivity lift from generative AI in software development at 20–45%, which is great for application teams and a problem for platform teams trying to keep up with the resulting feature flow. Infrastructure investment is climbing on both fronts: more spend on the compute that trains and serves models, more spend on AI tools that manage everything else.
+The pressure to get this right is real. [McKinsey research](https://www.mckinsey.com/capabilities/mckinsey-digital/our-insights/the-economic-potential-of-generative-ai-the-next-productivity-frontier) puts the productivity lift from generative AI in software development at 20–45%, which is great for application teams and a problem for platform teams trying to keep up with the resulting feature flow. Infrastructure investment is climbing on both fronts: more spend on the compute that trains and serves models, more spend on AI tools that manage everything else.
 
 This guide covers both categories: the compute and MLOps stack in Part 1, and AI-powered infrastructure management in Part 2, where the more interesting product shift is happening.
 

layouts/partials/schema/graph-builder.html

@@ -45,10 +45,19 @@
      main-entity.html already returns FAQPage as their *main* entity, so adding it
      again here would duplicate it in the @graph. faq-entity.html safely returns an
      empty dict when no question-shaped headers are found, so this is a no-op for
-     the many docs pages that have no FAQ section. */}}
+     the many docs pages that have no FAQ section.
+     Blog posts opt in explicitly via `faq_schema: true` in frontmatter: unlike
+     what-is/docs pages (curated, definitional, low false-positive risk), 168+
+     existing blog posts contain narrative headings that happen to end in "?"
+     without being a real Q&A section, so gating blog FAQ schema on type alone
+     would generate inaccurate structured data across the archive. The opt-in
+     flag keeps this a reusable template mechanism (not a per-page hack) while
+     avoiding that regression; add `faq_schema: true` to any blog post's
+     frontmatter once it has a genuine FAQ section (## or ### headings ending
+     in "?") to pick up FAQPage schema automatically. */}}
 {{ $faqPage := dict }}
 {{ $isDedicatedFaqPage := or (strings.Contains (lower .RelPermalink) "/faq") (strings.Contains (lower .Title) "faq") (strings.Contains (lower .Title) "frequently asked") }}
-{{ if and .IsPage (or (eq .Type "what-is") (eq .Type "docs")) (not $isDedicatedFaqPage) }}
+{{ if and .IsPage (not $isDedicatedFaqPage) (or (eq .Type "what-is") (eq .Type "docs") (and (eq .Type "blog") .Params.faq_schema)) }}
   {{ $faqPage = partial "schema/collectors/faq-entity.html" . }}
   {{ if and $faqPage (ne $faqPage (dict)) }}
     {{ $faqPage = merge $faqPage (dict "@id" "#faq") }}