Tracking Search Intent

Tracking Search Intent: Metadata, FAQ Schema, and the Content Operating System

This section documents implementation that is partially built and actively in development. Current build state is described honestly, what is deployed, what is partial, and what is architecturally intended but not yet complete.

Two Layers of the Same Strategic Field

Every page in a SCOS-managed site carries a Search Intent Goal. The question being answered is the same regardless of how it is stored.

What changes is, what the system can do with it.

The human/strategy layer, a plain-language question recorded as free-text.

Readable by editors, visible in admin columns, exportable to content inventory. Answers the question: what is this page for? This layer works without any additional module activation and is the entry point for all sites.

The machine layer, the same question linked to a structured FAQ Custom Post Type (CPT) object.

The question is now a content entity in its own right, with a post ID, a completeness status, schema generation potential, and cross-page reuse capability. It can be answered, audited, cross-referenced, and read by agents traversing the content graph. This layer is what the framework is building toward.

The upgrade path is deliberate: free-text is not wrong. It is the migration target for legacy planning notes and the fallback when the FAQ module is not active. The FAQ linkage is the structured form, the point at which a planning decision becomes a first-class strategic object.

The FAQ CPT as Strategy Object

In most WordPress implementations, FAQ content types are display objects, questions and answers formatted for a page section or accordion. In SCOS, the FAQ CPT carries a different role.

When a page’s Search Intent Goal is linked to an FAQ post, that FAQ is flagged as a strategy object (scos_faq_is_intent_goal = 1). This flag distinguishes it from display FAQs. It marks the question as the primary intent of a specific piece of content, not a supplementary question on a page, but the central question the page exists to answer.

FAQ as Search Intent Goal and strategy object

1. Essentially it creates completeness tracking. A FAQ linked as an intent goal but without an answer is a stub, it has been named but not answered.
   The system surfaces these as “Needs answer” badges in the admin, making content gaps visible at inventory level rather than requiring manual audit.
2. Reverse lookup. The FAQ admin shows which pages use each FAQ as their intent goal.
   This makes it possible to see at a glance how many pages are built around a particular question, and to identify where intent goals may be overlapping or where a single FAQ is being used as the primary intent for multiple pieces of content, which is a structural signal worth investigating.
3. Schema generation potential. A structured FAQ with a question and answer is the correct input for FAQPage schema.
   When the intent goal is stored as a free-text note, schema generation requires additional manual steps. When it is stored as a linked FAQ CPT with a complete answer, schema generation can be automated from the same object that drives the content strategy assignment.
4. Cross-page reuse. The same FAQ can appear as a supporting question on multiple pages while being the primary intent goal on one. The flag distinguishes these roles. An agent reading the content graph can tell the difference between “this page is built to answer this question” and “this question appears on this page as supporting context.”

The Resolver Architecture

All consumers of the Search Intent Goal read through a single class: Intent_Goal_Resolver. This is the MCP-first pattern, business logic lives in one place, and every other system (admin UI, REST endpoints, GA4 data layer, Airtable sync, content inventory export, WP-CLI) calls the same resolver rather than reading raw meta directly.

The resolution order is:

1. FAQ post title, if a valid FAQ post ID is linked (scos_ca_intent_goal_faq_id), the FAQ’s post title is the intent goal question
2. Free-text field, scos_ca_intent_goal, the current structured free-text field
3. Legacy field, bw_search_intent, previous field name, still resolved for unmigrated sites
4. Legacy notes, bw_altc_notes, original planning notes field, the oldest migration source

This resolution order means the system is backwards-compatible (with software evolving with the frameworks maturity). Sites that have not yet migrated to the structured FAQ linkage continue to work. Sites that have migrated get the richer structured form automatically. The resolver decides which layer to read, consumers do not need to know which layer is populated.

What Is Currently Deployed

In site-essentials (the new architecture):

• The core infrastructure is built and wired.
• Meta fields are registered, scos_ca_intent_goal (free-text textarea) and scos_ca_intent_goal_faq_id (integer, FAQ post ID), in Meta_Fields.php.
• The resolver class (Intent_Goal_Resolver.php) is loaded by the ContentArchitecture Module.
• The admin UI includes a FAQ picker with stub creation, an editor can search existing FAQs, link one as the page’s intent goal, or create a stub FAQ (question only, answer to be filled later) directly from the content editing screen.
• Admin columns show the resolved intent goal with completeness badges where the FAQ module is active.
• The content inventory export (an Agentic workflow) includes both the free-text field value and the resolved FAQ reference.

In brighter-core (the consumer layer):

• The CAR injection (scos-car-injection.php) reads the intent goal via the resolver and exposes it as window.scosCAR.search-intent, making it available to GA4 for custom dimension tracking.
• Airtable sync reads the intent goal via the resolver and exports both the resolved question and the raw FAQ post ID.

The FAQ module gate:

The structured FAQ picker UI and the reverse-lookup functionality only appear when SCOS_FAQ_ACTIVE is defined, the FAQ submodule is enabled on a per-site basis. Without it, the system uses the free-text field only. The resolver and free-text storage work in all configurations. Structured FAQ linkage requires the module to be active.

What Is Partial or Not Yet Complete

Legacy REST API endpoint. The class-brighter-api-endpoints.php REST endpoint still reads from bw_altc_notes directly rather than routing through the resolver. This means external consumers reading via the legacy API endpoint get the oldest layer of the data rather than the resolved current value. Migrating this endpoint to the resolver is a known gap.

Content Authority Map (CAM). The README marks the CAM as not yet built. The intent goals stored across the content inventory are intended to feed the CAM, a view that maps how intent goals distribute across clusters, topics, and maturity levels, and identifies coverage gaps and overlaps. The data exists. The aggregation layer does not yet.

FAQ answer completeness at scale. The stub creation workflow allows intent goals to be linked to FAQ objects before answers are written. The completeness badges surface this in the admin.

What does not yet exist is a site-wide completeness audit, a view showing the proportion of intent goals across the full inventory that have linked FAQs with complete answers versus stubs versus free-text only. That audit view is architecturally straightforward given the resolver and the completeness flag, but has not been built.

The Architectural Intent

The FAQ CPT as intent goal object is the mechanism for closing the gap between content strategy as a planning activity and content strategy as a structured, machine-readable, operationally trackable system.

A free-text note in a meta field answers one question: what is this page for? A linked FAQ object answers several: what is this page for, has the question been answered, is schema generated, which other pages address this question, and what is the completeness status of intent goal coverage across the site?

The longer-term architectural direction, consistent with the agentic execution model documented in Section 4 Designed for Agentic Execution and AI Visibility, is that an agent querying the content inventory should be able to read the intent goal for every page as a structured, typed, queryable value. Not infer it from the content. Not extract it from a free-text note. Read it from a field that the framework has already populated.

The resolver is the current mechanism for that. The FAQ linkage is the upgrade that makes the intent goal a full content entity rather than a metadata annotation. Both are in active development.

For the technical implementation detail of the broader SCOS content metadata architecture, see SCOS: The Operating System, Section 13 of this framework, currently in development.