Discoverable vs Understandable vs Citable vs Routable: The DUCR Model for Service Business Websites

A website can leave several different questions unresolved: can a platform access an important page, can a buyer understand the service, is there useful evidence, and does the next step work?

Use DUCR to organize those questions before choosing work:

• Discoverable: what do current access and search records show?
• Understandable: is the service and intended audience clear?
• Citable: are important explanations and supporting sources useful?
• Routable: can the visitor take the appropriate next step?

For direction on your site, request the free Outside View or bring your priority to a Clarity Call.

The model

DUCR is our review framework. It helps separate observations, unknowns and possible changes. It does not establish why enquiries are weak or require work in a fixed sequence.

Google’s current guidance says ordinary SEO remains relevant to its AI features, without special AI schema or a prescribed writing format. OpenAI separates search access from training permissions. Apply those platform rules where relevant; our framework’s labels and points are not their ranking factors.

Primary sources: Google AI optimization guide and OpenAI crawler documentation. The benchmark methodology records the current interpretive sources and review date.

The DUCR model in one table

Layer	Question for the review
Discoverable	Can the intended pages be reached, and what do current indexing and access checks establish?
Understandable	Can a suitable buyer identify the service, its scope and the job of each page?
Citable	Are important explanations and claims supported by relevant evidence?
Routable	Does the visitor have a useful next step that works?

Start with one priority page

Choose a service page that matters to the business. Record what you observed, what remains unknown and the next check that would change your decision. A field you have not checked is unknown, not a failure.

Use the readiness worksheet for a structured first pass or the business scorecard to define the outcome. The June benchmark score is a separate historical 100-point rubric, not a threshold for buying work.

The four composite examples below are illustrative situations, not reported client results.

Layer 1: Discoverable

A page is discoverable when search and AI-assisted systems can reach it, crawl it, index it where appropriate, and reinforce it through a clean internal structure.

A URL existing is only one observation. Check the intended access, current indexing state and relevant internal connections separately.

What good looks like

• The service page is linked from relevant hubs, menus, and related pages.
• There are not multiple near-duplicate URLs competing as the real page.
• Unintended crawl restrictions, login requirements or rendering problems are investigated. Redirects and canonicals are interpreted according to their purpose, not treated as automatic blocks.
• Important pages have useful crawlable links. A working dropdown link is still a link; context and reachability matter.

Quick check questions

• Can a reader find this page through relevant navigation or contextual links?
• Does the page have contextual internal links pointing to it from related content?
• Is the page competing with duplicates, parameters, archives, or alternate templates?
• What do current indexing evidence and the intended canonical show?

Possible issues to investigate

• An important service page is difficult to find through relevant navigation.
• Blog posts mention the service but never link to the service page.
• Near-duplicate pages repeat the same main content without a distinct reader purpose.
• Templates create large-scale duplication through tags, archives, or faceted variants.

Possible changes after checking

1. Ensure key pages are reachable with clean internal links.
2. Investigate genuinely duplicate main content and the intended canonical; retain pages that answer distinct questions.
3. Validate crawl and index stability on revenue URLs.
4. Fix template behaviors that create repeat confusion at scale.

Use the important-page indexing guide to distinguish a missing index entry from weak search visibility. A confirmed access problem may belong in Technical SEO.

Illustrative composite example

A home service business has a services dropdown with 14 items. The emergency service page is only reachable through that dropdown and has almost no internal links from related posts.

Possible concern to check:

• Is the service page receiving relevant search exposure?
• Do navigation and related articles help the reader reach it?

Possible changes after checking:

• Add contextual internal links from relevant support content.
• Strengthen hub-to-service page relationships.
• Clean duplicates so one page is the reinforced owner.

Layer 2: Understandable

The site is understandable when service language is stable and the page system makes it obvious what the business does, what each service means, and which page should own which intent.

A technically available page can still leave its audience or service scope unclear. Check the wording against the questions suitable buyers actually ask.

What good looks like

• One page clearly owns one service intent.
• Headlines and H1s name services in plain language.
• The same service is not described by three different names across pages.
• Support pages support the owner page instead of stealing its job.

Quick check questions

• Can a new visitor identify the service and whom it is for without searching across the site?
• Do service names match across navigation, service pages, internal links, titles, and headings?
• Are two pages trying to mean the same thing?
• Does support content strengthen the service page or compete with it?

Possible issues to investigate

• Mixed terminology for the same offer.
• Broad “solutions” pages that try to cover everything.
• Support content repeats the same decision without adding a useful answer.
• Search results lead to a page whose job does not match the reader’s question.

Possible changes after checking

1. Choose the owner page for each core service intent.
2. Define service names and enforce stable usage.
3. Rewrite opening sections so each page’s job is unmistakable.
4. Preserve useful distinct pages. If the same decision is repeated, investigate whether to keep, reposition or combine them using the overlapping-pages guide.

Illustrative composite example

A B2B service firm offers one core service, but uses three labels across the site:

• SEO Growth
• Content Authority
• Enquiries

Those labels appear across different pages with similar copy.

Possible concern to check:

• Can a buyer tell whether these names represent different services?
• Do the pages answer distinct questions, or repeat the same offer?

Possible changes after checking:

• Decide the primary service label.
• Map sub-services as supporting concepts, not duplicate offer pages.
• Rebuild headings and internal links so one page owns the meaning.

Layer 3: Citable

A page is citable when important answers and decision support are stated explicitly enough to summarize without guessing.

Use the Citable lens to inspect clear explanations and supporting evidence. It does not establish that an assistant will quote the page. An FAQ is useful only when it answers a real question.

What good looks like

• Key questions are answered in clean sections: process, pricing factors, timelines, fit, non-fit, proof, and what happens after contact.
• Proof appears near decision points, not buried in the footer.
• Claims are specific enough to trust.
• The page has useful extractable blocks, not vague paragraph fog.

Quick check questions

• Does the page answer the top decision questions directly?
• Are important answers placed under clear headings?
• Is proof visible near the CTA?
• Could someone quote a useful “why, how, or what happens next” block?

Possible issues to investigate

• Long introductions with no direct answers.
• “Custom pricing” with no pricing factors.
• No process section, so the service feels abstract.
• Proof exists but has no context.

Possible changes after checking

1. Add decision sections: process, fit, pricing factors, timeline factors.
2. Add proof blocks with context.
3. Remove filler and make answers explicit.
4. Keep FAQs small and real.

For a practical page plan, use the service-page structure guide and proof selection guide.

Illustrative composite example

A consulting page says:

• “We tailor solutions to your needs.”
• “Pricing varies.”
• “Contact for details.”

Possible concern to check:

• Can a buyer understand the work or the factors that affect scope?
• Is there a relevant example supporting the service claim?
• What would they still need to ask before contacting the team?

Possible changes after checking:

• Add “how we work” steps.
• Add “what changes cost” factors.
• Add “what results look like” with examples.
• Add “who this is for” and “what happens after contact.”

Layer 4: Routable

A page is routable when discovery does not end at a page view. The visitor can move into the right service page, proof section, and inquiry path without hunting.

A page view alone does not show whether the next step was relevant or completed. Inspect the route and received enquiry records before drawing a business conclusion.

What good looks like

• Support articles link contextually to the owner service page.
• CTAs are clear and consistent.
• The contact path is easy on mobile.
• Proof supports the next step instead of sitting as decoration.

Quick check questions

• Does the article offer a relevant next step where the reader needs it?
• Is there one obvious CTA, or five competing actions?
• Can someone complete the contact action on mobile, and is the enquiry received?
• Do proof elements route toward contact?

Possible issues to investigate

• Support content ranks but does not route.
• Visitors land on informational pages and exit.
• CTAs are vague or scattered.
• Contact is buried, slow, or form-only.

Possible changes after checking

1. Add or improve a contextual next-step link where it answers the reader’s remaining question.
2. Simplify to one primary CTA.
3. Put proof near decision points.
4. Reduce mobile friction.

Illustrative composite example

A service business ranks for:

• “how much does service cost”
• “best service near me”
• “what to expect from service”

But every post ends with “contact us for more information.”

Possible concern to check:

• Does the reader need a service explanation, proof or a conversation next?
• Does the current closing link make that destination clear?

Possible changes after checking:

• Add contextual links to the owner service page.
• Explain what happens after booking.
• Add proof modules near the CTA.

What to fix first when multiple layers fail

Prioritize a confirmed issue by business effect, urgency, effort and dependencies. A broken enquiry form may need a repair now. An unclear service scope may need a focused rewrite. A low rubric score without an identified buyer problem may need investigation rather than implementation.

The number of weak categories does not establish whether a rebuild is appropriate. Compare the specific constraint and repair options using the rebuild decision guide.

DUCR scorecard

Use a short decision record instead of treating a total as a purchase instruction:

Record	What to write
Page and business question	The service and decision you want this page to support
Observation	What you checked, when and the evidence retained
Unknown	What the current evidence cannot establish
Next check or change	The smallest useful step, who owns it and why it matters
Follow-up	How you will confirm the task worked and review the business result

Next step: get the bottleneck diagnosed

Bring the page and the question. We can discuss whether the next step is a repair, clearer information, further investigation or no immediate change. Request the free Outside View or a direct Clarity Call.