GooseARWP
GET FOUND.

A PRACTICAL FIELD GUIDE TO SEARCH & AI DISCOVERY

Get
Found.

Start with the problem your site should own. Then improve only the content, evidence and technical surfaces that help people — and machines — solve it.

Find a patternDefine the boundary
Patterns
219
Sources
132
Problem lanes
3
Core
Open source
An illustrated goose carrying a note: Show your sources.

SITE FOCUS / BEFORE OPTIMIZATION

Own a problem.
Draw the boundary.

A useful resource gets weaker when every adjacent topic becomes a first-class section. Scope is part of the product: say what belongs, what stays subordinate and what does not belong here.

1primary problem territory
≤3homepage problem lanes
≤5primary nav destinations
1dominant action per page
GOOSE / WE DO

Turn a useful, focused site into a better discovery surface.

  • Decide which Search, AI and agent-web changes actually apply.
  • Improve access, answer quality, evidence and machine-readable routes.
  • Keep source support and implementation verification inspectable.
  • Measure search, citation, recommendation and useful-action outcomes separately.
GOOSE / WE DO NOT

Become another everything-about-SEO content mill.

  • No guaranteed rankings, citations or recommendation claims.
  • No generic publishing volume as a substitute for a site thesis.
  • No universal AI manifest that replaces native standards.
  • No opaque readiness score that hides what actually changed.
Use the Site Focus playbook →

THREE PROBLEMS, NOT THIRTY FEATURES

Choose the gap your site has.

The homepage routes work by problem. Protocols, schemas, tools and research stay available one level deeper instead of competing as separate product identities.

01 / BE FOUND

Can they reach the useful thing?

Fix crawlability, discoverable routes, internal structure and the specific technical surfaces that make sense for the site.

Find an applicable pattern → 02 / BE USED

Is the answer worth using?

Strengthen original evidence, direct answers, comparisons, data, tools and page structure instead of adding filler.

Improve the useful surface → 03 / BE PROVEN

Did the change help?

Separate implementation checks from real search, citation, recommendation and useful-action outcomes. Keep neutral results too.

Run the Growth Loop →

House heuristic, not a ranking rule: one core problem, up to three first-order lanes, up to five primary navigation destinations and one dominant action per page. Change the architecture when the site's real audience gives you a better reason.

FROM FOCUS TO EVIDENCE

Useful beats noisy.

Do less, but make each change explainable: why this page exists, why this pattern applies and what signal will tell you whether it worked.

01 / SCOPE

Write the site thesis.

Define the audience, problem, useful outcome, IN/ADJACENT/OUT boundary and the page job before adding another route.

Open Site Focus
02 / CHANGE

Use evidence, not folklore.

Select a small number of applicable patterns. Keep sources, versions, implementation checks and limitations attached.

Explore the pattern library
03 / LEARN

Measure what matters.

Connect technical checks with actual search, citation and useful-action results. Preserve null and negative outcomes.

Start an improvement loop

EVIDENCE MODEL

Useful claims need visible limits.

Goose keeps source support, implementation verification and outcome evidence separate. A technically correct change is not automatically a ranking or recommendation win.

SOURCE

Why try it?

Primary guidance, reviewed research or explicitly labeled project hypothesis.

CHECK

Did we build it?

Generated output, links, semantics, accessibility and repository checks.

RESULT

Did behavior change?

Search, citations, recommendations and product actions remain separate observed outcomes.

LIMIT

What is not proven?

Unknown, unmeasured and neutral results stay visible rather than being converted into success language.

Technical depth / ResolverAgents, APIs, standards

THE INTEROPERABILITY FOUNDATION

Help agents find their way around.

Without a resolver

  1. Search or scrape the site
  2. Guess which discovery file matters
  3. Read incompatible metadata shapes
  4. Silently choose when declarations disagree
  5. Lose why an interface was trusted
Integration depends on site-specific logic.

With ARWP Resolver

  1. Observe bounded public discovery
  2. Normalize existing standards and conventions
  3. Keep source authority with every interface
  4. Surface conflicts instead of hiding them
  5. Plan the best interface for the intent
Integration starts from inspectable evidence.
Website resolverCLI ready

Resolve all discovery
node bin/arwp.mjs resolve https://example.com
Explain what was found
node bin/arwp.mjs explain https://example.com
Plan for search
node bin/arwp.mjs plan https://example.com --intent=search
Observe / bootstrap ARWP profile
node bin/arwp.mjs scan https://example.com
node bin/arwp.mjs init https://example.com

The resolver treats ARWP as one publisher source, not a mandatory universal manifest. Native standards keep their own semantics.

Technical depth / ReferencesImplementations, directory

WORKING REFERENCES

Explore the working reference sites.

Owner-controlled examples are implementation fixtures, not independent adoption evidence.

Loading the public directory…

Publisher profile example

Choose a reference site

The profile is one explicit source the resolver can consume.

/ai/site-profile.json

ARWP Directory

Inspect a real implementation.

The directory records current reference sites that publish ARWP.

Machine-readable directory JSON →

Technical depth / Research infrastructureRouter, benchmark, standards
FED

Federated router

Search across resolved heterogeneous sites while preserving interface evidence.

View router →
BENCH

Benchmark utility before expanding the format.

The interoperability foundation should earn additions through observed failures and independent evidence, not new AI vocabulary.

Benchmark methodology →
STD

Resolve, do not replace.

RFC, A2A, Agent Skills, MCP, OAuth and API metadata keep their own semantics and authority.

Resolver contract →