Editorial standards

Writing rules for a source-backed compliance site

BackflowPath is not supposed to sound like a generic SEO education site. The public copy should clarify the local rule, preserve the official source, and keep sponsor or provider language visibly separate from utility authority. Editorial quality on this site is defined by trust, legibility, and restraint, not by word count alone.

Language

Use searcher language, not internal shorthand

Headlines and summaries should describe what the user is trying to do: annual testing, approved testers, failed test next steps, reporting portal, or penalties. Internal categorization terms should stay out of public titles unless they match how people actually search.

Claims

Never overstate authority status

BackflowPath should only call a tester approved, certified, or official when the governing authority itself uses that status. If the site is showing a discovery path instead, it must be labeled as non-official or directory-only.

Monetization

Commercial routing is downstream

Lead capture, sponsor callbacks, and provider profiles can exist, but they should appear after the official workflow and source block. They are support actions, not the definition of the rule.

Title and summary rules

What a page should sound like

  • Use the utility or authority name in the main title when that is the governing entity.
  • Lead with the actual user task: annual testing, approved testers, failed test next steps, fire line, irrigation, reporting portal, or due date.
  • Keep summaries concrete enough that a searcher can tell what the page covers before clicking.
  • Avoid internal taxonomy language unless it matches common search behavior.
Source usage

How sources should appear in the copy

The site should not bury the source block at the bottom and then ask the user to convert. The official route, source excerpt, submission path, and contact channel should be visible early enough that a cautious user can verify the page before taking the next action.

Required page elements

What every strong local page should include

  • Last verified date and verification code
  • Official source URLs and source excerpt
  • Submission method and utility contact path
  • Tester routing labeled by authority status
Failure conditions

When a page should not stay indexed

  • The source can no longer be verified.
  • The page no longer adds utility-specific value.
  • The route is a thin bridge that should be canonicalized elsewhere.
  • The page implies authority or approval it cannot support.
Support content rule

How guides should behave

Guides can explain repeated patterns such as anniversary dates, reporting portals, or tester classifications, but they should still route readers back to the exact utility page before a practical decision is made. Support content is a translation layer, not a replacement layer.

Provider content rule

How provider pages should behave

Provider profiles should read like inspectable public records, not promotional landers. They need real entity signals, route classification, and explicit separation from official program status.

Editorial posture

Preferred failure mode

When the tradeoff is between being broader and being clearer, BackflowPath should choose clarity. When the tradeoff is between indexing a questionable page and waiting for stronger source support, it should choose patience.