Profiles

Every rule goflag ships records how authoritative the requirement behind it is: whether a published standard demands it, a vendor documents it, or it is widely-repeated folklore. That is a fact about the world, and goflag never fudges it.

What your build should do about each one is a different question, and the answer is yours. That is what --profile sets.

goflag https://example.com --profile spec-only    # only what a spec backs
goflag https://example.com --profile strict       # spec-backed rules fail the build
goflag https://example.com --profile marketing    # metadata gaps are errors

The four profiles

What a profile can and cannot change

A profile has exactly two levers per rule: whether it runs at all, and how loudly it fires. It never changes what a rule observes, and — the part that matters — it never rewrites a rule's stated authority.

So strict can make a heuristic finding fail your build, but it cannot turn folklore into a spec requirement. The finding still reports "rigor": "heuristic", and anyone reading the report can still tell the difference. This is deliberate: an overlay that could launder authority would destroy the one thing the rigor scale is for.

That is also why strict leaves heuristics at warning rather than promoting everything indiscriminately. Google states outright that title length is not a ranking factor; a profile that failed builds over it would be lying with the tool's own vocabulary.

spec-only removes rules, it does not quiet them

The heuristic rules are switched off, not lowered to info. A disabled rule is absent from the conformance view entirely rather than sitting there as a suspiciously quiet pass — "not run" and "never applied" are different claims, and conflating them would make the matrix lie about coverage.

The practical consequence is that a profile can change the verdict, not just the wording:

$ goflag https://example.com/page --depth 0
YELLOW FLAG   title.length, description.length
 
$ goflag https://example.com/page --depth 0 --profile spec-only
GREEN FLAG    No problems found.

Both runs are honest. The second one means "nothing a specification backs is wrong here" — which is a narrower claim than "nothing is wrong", and the reason the profile is recorded in the report.

Profiles and baselines

The report records which profile produced it, and the terminal names any non-default one next to the crawl counts. That record is load-bearing when you gate on a baseline: comparing a run against a baseline captured under a different profile still works, but 0 new findings no longer means what it appears to.

goflag says so rather than letting the number speak for itself:

REGRESSION GATE  0 new · 19 known findings NOT gating this build
baseline https://example.com — taken 2026-08-06 (today)
note: baseline was captured under profile `strict`, this run used `spec-only` — the two are not like-for-like.

It is a warning and never a gate. Investigating with --profile spec-only against a strict baseline is a legitimate thing to do; doing it without noticing is not.

Picking one

Most projects want default, and should reach for another only with a reason:

• strict when the site is already clean and you want it to stay that way. It has no mercy for a vendor-spec rule you were treating as advisory.
• spec-only when the length-window warnings are noise you have decided against, and you would rather they disappear than be ignored. An ignored warning trains people to ignore warnings.
• marketing for a site whose pages exist to be shared, where a missing preview image costs a click whatever the specification calls it.