What MCP-Listed Websites Teach Small Businesses About the Stack

Start with a website people can use, facts they can find and a clear route to enquire. Then decide whether an AI connector solves a customer problem worth maintaining. Our directory-led study shows how to separate those jobs. This week, check your home page and your main service or contact page, assign the first repairs, and record a baseline before changing anything.

An MCP directory is a useful place to find organizations experimenting with AI assistants. MCP means Model Context Protocol, a way for an assistant to use a service's named functions. An MCP server supplies those functions; a connector connects the assistant to them. A function called a tool might return available appointments. Its endpoint is the address where software sends the request.

A registry is a catalog of technical listings. An assistant directory presents connections people can choose, sometimes under the label plugin. These are useful research leads. A directory listing is not a website quality certificate.

We built a fixed sample of 72 organization websites using the official MCP Registry, the Claude directory, and the ChatGPT directory. The selection, denominators and read times appear in the study method below. The findings describe public website surfaces. We did not connect to any sampled MCP service or attempt a transaction.

What the study found

11 of the 72 selected sites (15.3%) demonstrated broad publication coverage under our indicator: at least 18 of 24 signals, with at least two in each of six groups. Another 22 were indeterminate because unresolved evidence could change the result; 39 fell below that editorial threshold even under the favorable unknown-result bound. This is the answer to “most of the stack” that these passive observations can support. It is not a count of fully compliant or operationally tested websites. Definitions and coverage.

We could measure initial home-page HTML for 62 of 72 sites. All 62 had a nonempty title, HTTPS and a device-width viewport; 61 had a meta description. Those are useful foundations. More uneven signals included labels, skip links, canonical declarations, connector documentation and response headers. The table separates observed absence from unknowns. Each percentage uses only the assessed cases in its row. Study measurements, November 7.

“Not observed” includes a missing signal or an unsuitable file response at the measured location. The table is not a list of universally required additions. Outside-source links, public addresses, opening hours, review dates and optional machine files need a reason to exist. For a small business, the 12 observed form-label gaps and 12 absent canonical declarations are more useful starting questions than adding every optional file merely to raise this indicator. Initial-HTML label results still need review in the live page. Measurement definitions.

We confirmed 12 connector-specific data-handling disclosures; the other 60 remained unknown under the limited page budget. We did not call those missing policies. Among the 62 measured homepages, exact JSON-LD types included Organization on 44, LocalBusiness on 1, FAQPage on 16, Product on 2, Event on 1 and Offer on 21. Types can overlap. The broader identity check also recognized relevant organization/business subtypes and passed on 46 homepages. Appropriate schema depends on what the organization actually does. Study measurements.

Crawler choices were mixed rather than a single universal allow policy. Of 65 readable robots documents, 33 contained selected named AI-related groups. For the exact GPTBot token, 20 policies allowed the root and 10 disallowed it; for ClaudeBot the counts were 18 and 8. All 26 explicit PerplexityBot policies allowed the root. These counts describe published rules. They do not show actual crawler access, and we are not recommending a policy. Study measurements.

Read “missing” carefully. An absent attribute on a measured image is a different finding from a file we could not read. A business with no published opening hours may operate entirely online. A website can have a useful help center even when its home page contains no question-and-answer section. We report the measured location and keep unknowns separate.

The same caution applies to the phrase “whole stack.” WCAG, the Web Content Accessibility Guidelines, covers accessibility requirements. SEO means search engine optimization: helping search systems find and understand useful pages. AEO, answer engine optimization, means making answers explicit. GEO, generative engine optimization, is the planning label we use for making information usable in generated answers. MCP adds a callable service. Security spans all of those layers. AEO and GEO do not supply a universal certification or a single authoritative score.

Our coverage indicator is an editorial comparison of observable signals. It cannot establish WCAG conformance, indexing, AI citations, safe account access or successful sales. The W3C preliminary-check guidance explicitly treats initial checks as only part of accessibility evaluation. That limitation matters even more for the restricted rendering used here.

Positive examples: copy the decision behind the feature

The following sites met our editorial breadth threshold. These observations illustrate individual strengths; the threshold is not an overall compliance finding.

Meow Apps: make the connection route understandable. Its linked WordPress connection guide distinguishes connection routes, explains access and revocation, and states a connector-specific storage policy. We read the guide on November 7 at 21:13:31 UTC. Its home page, read at 21:13:29, also supplied a language declaration, title, image alt attributes and form-label signals in the initial HTML. The useful pattern is a human explanation that covers setup and data handling together. A small business can borrow that documentation structure without making the same storage promise unless its implementation supports it.

HubSpot: explain effects and data handling where people connect. The linked connector page explicitly describes “read and write access” and answers a connector-related data-use question. We read it on November 7 at 21:17:10 UTC. That makes the kind of access visible before a person connects. Our pass concerns the published explanation; we did not independently verify the vendor's or assistant provider's handling of data.

A one-person consultancy: say what gets retained. One sole-trader site in the sample, a retail-media measurement practice we are not naming, has a privacy page with a dedicated public MCP section describing call-log fields and retained questions or notes associated with particular tools. We read it on November 7 at 21:22:18 UTC. Its home page, read at 21:22:16, supplied organization JSON-LD and all three measured security headers. Those are inspectable publication signals; header presence does not establish effective configuration. The transferable lesson is specificity: a reader should be able to distinguish a public answer service from what the service records about a request.

Shorty: connect the privacy policy to the actual feature. Its privacy policy describes connector result fields, onward sharing with the person's AI provider and tool-activity records. We read the policy on November 7 at 21:26:26 UTC. Its llms.txt index, read at 21:26:30, had a product summary and grouped links to public pages and guides. The useful pattern is a disclosure about the connector's actual information flow, alongside ordinary website privacy information. We confirmed that the disclosure was published. We did not check that every stated practice is implemented.

These are examples of specific observed passes. We are not endorsing a vendor or giving any named site an overall accessibility, security or operational grade. Study the relationship between a public promise, the visible facts and the place a person goes next. Write your own content and implementation.

For a small service business, that relationship could be straightforward. A page explains which repairs the business accepts, which area it serves and how appointment requests work. Structured data repeats the same identity. A connector, if justified, answers a supported question and returns the correct service page. The customer still reviews and sends the request.

For a nonprofit, replace the sales task with the actual service: finding a program, checking a published eligibility rule or locating an event. A program page needs a responsible organization, relevant geography, a source and a review date. A person's eligibility decision may require staff review. Our nonprofit, events and WordPress connector guide develops those patterns without assuming every organization should offer a booking tool.

Add the layers in a useful order

The full stack: the order for a small business

┌────────────────────────────────────┐
│ 1. Accessible, fast pages          │
│ Keyboard, labels, contrast, zoom   │
│ A clear task on a phone            │
└────────────────────────────────────┘
                  ▼
┌────────────────────────────────────┐
│ 2. Search basics                   │
│ Titles, links, sitemap, HTTPS      │
│ Useful pages people can find       │
└────────────────────────────────────┘
                  ▼
┌────────────────────────────────────┐
│ 3. Structured answers              │
│ Visible facts and genuine FAQs     │
│ Schema matches the page            │
└────────────────────────────────────┘
                  ▼
┌────────────────────────────────────┐
│ 4. AI readiness                    │
│ Plain HTML, intentional bot rules  │
│ An optional, useful llms.txt       │
└────────────────────────────────────┘
                  ▼
┌────────────────────────────────────┐
│ 5. A documented connector          │
│ A real task, clear limits, privacy │
│ A person confirms commitments      │
└────────────────────────────────────┘
                  ▼
┌────────────────────────────────────┐
│ 6. Listings and measurement        │
│ Keep descriptions current          │
│ Track enquiries, then sales        │
└────────────────────────────────────┘

Record your baseline before changes.

The sequence is our recommendation; no standard imposes it. Security and privacy work belongs alongside every step. The effort estimates below are planning allowances. We did not measure project times, and your platform may differ.

1. Make the important task usable

Who does this: the owner describes the task; the web person checks the page; an accessibility specialist handles issues that need deeper evaluation. Effort: an initial focused review, followed by repair work sized from what it finds.

Choose a task that matters to the business: understand a service, compare a product, find an event or request a callback. Try it with a keyboard. Enlarge the text. Read the labels and error messages. Check that focus remains visible and that a menu does not trap the visitor.

Our structural checks covered the page's language declaration, title, image alternative attributes, form-label signals, heading sequence, main landmark and skip-link signal. An image's alt attribute gives its text alternative. A landmark identifies a page region, such as the main content. A skip link lets someone move past repeated navigation. Attribute presence alone cannot tell you whether the words are helpful.

The WCAG Accessibility Audit can identify issues to review. Keep a separate human checklist for the keyboard path, meaning of alternatives, reading order, errors and the actual colors. A clean machine result does not replace that work. W3C's Easy Checks gives owners a sensible first review.

Keep the page quick to use too: make the main message easy to find, avoid unnecessary media, and test the real page on a phone. This study did not measure page-speed performance. We are recommending that work because a customer has to complete the task before the website can generate an enquiry.

Done when: a person can complete the important path with keyboard and enlarged text, the detected issues have been reviewed, and remaining accessibility work has a named owner. Use the site launch design guide for component and layout decisions instead of rebuilding this process from scratch.

2. Put search basics around accurate content

Who does this: the owner verifies business facts and the web person checks the page template. Effort: a focused session for a small set of priority pages, with more time for broken templates or migrations.

Give each page a descriptive title and main heading. Write a description that helps someone decide whether the page answers their question. Choose a canonical address, meaning the preferred URL for that content. Check that links, redirects and the sitemap agree with it.

A sitemap is a list of page addresses for crawlers. Opening /sitemap.xml should produce the expected XML document. A normal web page served with a success code does not count. Our check required a parseable sitemap document at the requested address or its redirect. We did not follow every sitemap entry. Another valid sitemap location could exist outside that limited check.

Robots.txt publishes crawl preferences. Read the actual rules before copying a template over them. A restriction may be deliberate. Missing robots.txt is not, by itself, a search defect; the robots exclusion protocol distinguishes an unavailable file from rules that restrict a crawler.

Run the Mega Analyzer in passive mode on your own site to collect a starting set of observations. Review title, description, canonical, heading, mobile viewport and Open Graph results. Open Graph supplies page-preview information when a link is shared. Confirm the important business facts by reading the page, rather than treating a completed metadata field as proof of good copy.

Our title-length check is only a house heuristic. Google's SEO Starter Guide does not turn a particular character count into a universal ranking requirement. Keep a useful title even when a simplistic length indicator complains.

Done when: the priority pages identify their purpose clearly, their preferred addresses agree, and the sitemap and crawl preferences describe what you intended to publish.

3. Make answers explicit and keep schema honest

Who does this: the owner supplies accurate answers; the web person publishes them and their matching structured data. Effort: a short writing session plus implementation and review.

Start with questions customers actually ask. What work do you do? Where do you serve? What should someone bring? Does a request confirm an appointment? What happens next? Put the answer in visible text close to the relevant service.

Schema.org supplies a vocabulary for describing those facts. JSON-LD is a format for attaching that description to a page. Organization describes an organization; LocalBusiness and its appropriate subtypes describe local businesses. A Product, Event or Offer needs the corresponding real subject. The Schema.org LocalBusiness reference shows relevant properties and relationships.

Use Schema Validator to inspect the markup, then compare every significant value with the visible page. A syntactically valid address can still be wrong. A service-area business should not invent a storefront to fill a field. An organization without public opening hours should not manufacture them to satisfy a checklist.

Be particularly careful with old FAQ advice. Google's current documentation updates, read for this article, state that FAQ rich results are no longer shown in Search. FAQPage remains a vocabulary type. Use it only for real visible questions and answers, without promising a Google display feature or an AI citation.

Done when: a visitor can find the important answers, the markup describes those same facts, and someone owns the next review. The downloadable kit includes original LocalBusiness and FAQPage examples with syntax checks; your business facts still need human verification.

4. Make AI-related choices deliberate

Who does this: the owner decides which public content to offer and the web person reviews the implementation. Effort: a short policy and content review; repairing a page that depends entirely on scripts can take longer.

Check what the initial HTML contains before page scripts run. HTML is the document a browser receives. A contact detail written only into an image, or important information loaded later by code, may be unavailable to a reader that does not execute that code. Our text-presence check is a rough starting signal. It cannot prove that every important fact is readable.

Publish sources where a reader needs to verify a claim. Use a truthful last-reviewed date for information that changes. Do not refresh dates automatically to make untouched content appear new. For services, the useful maintenance job is often keeping the service area, availability process and contact route accurate.

An llms.txt file is a proposed Markdown index for AI-oriented readers. The proposal provides a format; it does not establish that every assistant uses the file. Google's current documentation says llms.txt does not affect Google Search visibility or rankings. Treat it as an optional maintained index, below correcting the actual pages in your priority list.

Use LLMs.txt Validator to check its structure and AI Crawler Access Auditor to review published crawler choices. A declaration allowing a crawler does not prove that every request can reach the content, and a restriction can reflect an intentional business decision. Our study describes those policies without grading allow as good or block as bad.

Training, search inclusion and user-requested retrieval can have different controls. For example, Google's Google-Extended documentation describes specified Gemini-related uses and separates that token from Google Search inclusion. Check each provider's current documentation before copying names into robots.txt.

Done when: important public facts are readable, changeable claims have an owner and review process, and the published crawler choices match the owner's decision. Add an index file only when maintaining it is useful.

5. Build a connector only around a supported customer task

Who does this: the owner decides whether the task merits ongoing work; a developer designs and tests the service. Effort: a separate development project with continuing maintenance, so we give no fixed allowance.

A connector needs more than an endpoint address in a directory. Publish a human guide explaining its purpose, connection instructions, inputs, outputs, limits, support and privacy. Explain what information reaches the service, what gets logged, which providers process it and what the retention arrangements actually are.

Discovery files are public documents that help software identify a service. They can support that explanation. A file at a conventional address does not demonstrate that a service operates correctly, and the absence of one particular convention does not disqualify an otherwise documented connector. We read only the designated public files and never called the sampled services.

Use the Agent Endpoint Inspector with optional protocol checks off for a passive review. The MCP Server Audit is a broader GET-based checker for an owner-authorized service: it also reads endpoint addresses. That is beyond this study's files-only boundary. Neither a listing nor a public-file check proves that a booking or payment succeeds.

Write a concrete handoff. An assistant can supply the public service page or help fill a request; the person reviews and sends it. Commitments such as reservations and payments need their own permission, validation and failure handling. Our existing connector listing guide covers the documentation and review work, including lessons that a presence-only website check cannot reveal.

Done when: the supported task has an owner, documentation and privacy wording agree with the implementation, and authorized functional testing has been completed separately. Then use the directory listing guide to prepare distribution and maintenance.

6. Review security alongside the other work

Who does this: a developer or the hosting provider, with an owner responsible for the reporting contact. Effort: an initial configuration review and a separate estimate for changes.

We checked the home-page response for HSTS, Content Security Policy and X-Content-Type-Options: nosniff. HSTS instructs browsers to use HTTPS. A Content Security Policy restricts permitted page resources. The nosniff instruction limits reinterpretation of a response's declared content type. The OWASP Secure Headers Project explains these protections and their configuration considerations.

Presence is only the first question. A permissive policy can offer little protection. A hastily tightened policy can break a legitimate form or payment page. Use Security Headers to collect observations, then have the developer review the site's actual needs before changing it.

The security.txt file provides a vulnerability-reporting contact. RFC 9116 defines required fields, including contact and expiry, and makes clear that publishing the file does not grant testing permission. Our final checks distinguish a contact signal from a fully reviewed disclosure process.

Done when: applicable header policies have been reviewed and tested, and the published security contact has a responsible recipient and renewal date. These checks do not establish that a site is secure.

Revenue: measure the customer path, not the checklist score

Documented: nothing in this study. We measured no enquiries, purchases, search positions or AI referral traffic, and none of the sources cited here reports a revenue effect for these items. There is no revenue uplift number to transfer from these results to your business.

Plausible: the items closest to an existing customer action. A usable enquiry form can remove an obstacle. Clear service areas and terms can help people decide whether to contact you. Accurate product or event information can prevent confusion before a purchase. A useful connector can create an additional route into the same task. Treat each one as a change to measure.

No evidence: a canonical address, an accurate sitemap, a security contact or an llms.txt index. These are maintenance with indirect effects at most, and none of them supports a sales forecast.

Use a simple measurement sheet with aggregate counts:

Record a baseline and compare equivalent periods. Note advertising changes, holidays, staffing and unusual demand. If traffic rises while enquiries stay flat, review the customer path before assuming you need more technical files. If attribution is missing, mark it unknown. A before-and-after comparison can suggest a useful next test; it cannot isolate causation by itself.

For a nonprofit, use the equivalent service outcome: completed program enquiries, event registrations or successful handoffs to a staff member. Keep sensitive eligibility information out of the measurement sheet. The public website study should not become an excuse to build a new personal-data collection system.

Take the checklist to your web person

• Website best-practices stack checklist (.md): a one-page working checklist, week-one through quarter-one priorities, original llms.txt, robots.txt, JSON-LD and security.txt examples, and an aggregate measurement sheet.

Start with one important page and a defined customer task. Ask for evidence that the proposed change fixes the observed problem, then repeat the relevant check. Keep the result, owner and next review date together. That turns a one-time score into a manageable maintenance routine.

For owners connecting this work to a broader business plan, The $97 Launch puts the website in the context of choosing an offer and testing demand.

Study method and limits

Selection. We read the first 100 alphabetically paginated latest-version pages of the official Registry API from November 7, 2026, 21:06:51 to 21:10:43 UTC. This bounded frame covers only part of the registry. It ends in the com.iunera namespace, so alphabetical coverage is a substantial limitation.

The topic filter preferred travel, accommodation, restaurants, retail, property, gardening, public information, charitable work and educational publishing. It excluded descriptions centered on code, developer infrastructure, web-collection software, agent skills or cryptocurrency. Within the remaining domain list, we used a fixed hash ordering of domain names and took the first 48. That ordering was set before website measurement and did not use website scores. Domain matching is a selection heuristic. It does not independently verify who operates the site.

The other 24 organizations were a purposive mix of named makers in the supplied Claude and ChatGPT directory observations, including nonprofit services, business software, events and consumer commerce. Those observations were made on November 7 between 18:25 and 18:41 UTC, with additional consumer listings checked between 18:53 and 18:55 UTC. The Glama and mcptry public catalogs were also readable at 21:14:39 and 21:14:44 UTC; they were context checks and contributed no additional sample members. We did not replace any selected organization because of its response or score.

Coverage. All 72 selected sites completed the permitted sequence, with measurements from November 7, 2026, 21:12:27 to 21:35:43 UTC. All network evidence used direct reads. The captured-document browser analysis processed that evidence with network requests disabled, so it made no further reads.

Of the ten unmeasured homepages, six had an unreadable robots policy, one was disallowed by its policy, two had direct access responses that prevented measurement, and one led to an excluded account or endpoint path. We count these as coverage outcomes; they say nothing about the content. The reads came from a data center; they do not establish what a person sees from another connection. Owners can review whether their intended public pages and crawl preferences serve their intended readers while preserving account protections.

The seven designated file paths were evaluated for every site where policy permitted. The sitemap check had 63 assessed outcomes (51 parseable documents and 12 unsuitable or absent responses), with 9 unknown. Other file denominators appear in the findings table. Files at other addresses or a separate connector hostname were outside scope. Two supplementary browser observations supplied for otherwise unavailable homepages were retained separately and did not change the comparable direct-read counts.

The local axe-core version was 4.10.3, used for 62 captured-document analyses. There were 12 homepages without image elements and 35 without relevant form controls; their respective checks were not applicable. Visual and interactive accessibility remained unmeasured.

The request scope was public GET reads of robots.txt, the home page, at most one linked key page, sitemap.xml, llms.txt and these designated public files: /.well-known/mcp, /.well-known/agent-card.json, /.well-known/ai-plugin.json, /.well-known/ucp and /.well-known/security.txt. Key-page selection preferred same-origin connector, contact, product/service and privacy links, in that order. Redirects were recorded. An unreadable robots policy prevented further page reads. Published restrictions were respected. We used an identifying research client with at least two seconds between requests to an origin. No intermediary servers, sign-ins, form submissions, endpoint calls or protocol tests were used.

Rendering. We rendered captured initial HTML in a browser with page scripts and event handlers removed and network requests disabled. This kept the render within the specified page-and-file read boundary. It is not a normal live render with external styles and scripts. Locally available axe-core ran on those captured documents; its diagnostic rule and impact counts were retained, but visual results were excluded from comparisons. Live contrast, target sizing, visibility-dependent behavior and interactive states remain unknown. No speed test was run.

Definitions. Homepage-only checks covered HTML metadata, images, controls, headings, landmarks and response headers. The home page plus the permitted key page supplied answer, contact, review-date, source-reference and connector-documentation evidence. FAQ presence required an actual question-and-answer signal; marketing questions alone did not qualify. Source references received manual review for identified evidence supporting a claim, including specific linked reports or case studies and sufficiently identified methodology in visible text. Generic navigation, social badges and partner logos did not qualify. Presence did not establish source authority. Plain-text presence meant at least 500 characters after removing scripts and similar non-content elements. It cannot prove that every customer fact was readable.

The llms.txt signal required a title, summary and at least two links on the measured website's host. Content usefulness still needs review. Discovery required recognizable structured metadata in at least one of the four sampled discovery files. Security-contact coverage required a contact URI and a future parseable expiry. None of those tests establishes complete specification conformance. Connector privacy required manual confirmation of at least one published data-handling disclosure explicitly tied to the connector. This tests publication only. It does not test completeness or verify behavior; unresolved cases remained unknown. Documentation likewise required manual confirmation of connection instructions or an explicit guide link. A link alone does not verify its destination. Negative English-wording detectors were left unknown on non-English pages unless reviewed separately; the Q&A and source-reference checks received manual review across languages.

Breadth indicator. After a three-site pilot, we fixed the following editorial indicator before final aggregation: at least 18 confirmed signals out of 24, with at least two in each group below. We did not change the threshold to fit the results.

Unknowns can change a classification. We calculate both confirmed positives and the maximum possible positives if unresolved slots later pass. “Indeterminate” means those missing observations could change the threshold result. Pages with no relevant images or form controls contribute unresolved slots, rather than invented passes or failures; nobody should add an unnecessary form to earn a point. The indicator includes a directory point guaranteed by sample selection. Equal group weights and the one-H1 convention are our editorial choices. Neither WCAG nor Google requires them.

Limits. This sample favors early adopters and has a restricted registry alphabet, a topic filter and a curated directory component. It cannot estimate the prevalence of best practices among small businesses generally, nor prove that an MCP listing improves a website. Optional files, addresses, citations and dates are not appropriate requirements for every business. Every observation is a point-in-time read of a limited public footprint. Negative findings are anonymous aggregate counts; names appear only alongside verified positive observations.

Related reading

• MCP directories and the listing process
• Connector patterns for nonprofits, events and WordPress
• Big brands, MCP and agentic commerce
• Devpost projects and evidence of real revenue
• Grocery brands, checkout protocols and small businesses
• Design, search and AI in the site launch plan
• A working connector's documentation and listing requirements

Fact-check notes and sources

All dates below are in 2026 and all read times are UTC. Study counts are our own observations under the stated selection and measurement rules. They are not platform statistics or a representative small-business survey.

• Official MCP Registry API, November 7, 21:06:51 to 21:10:43: the bounded registry frame and listing metadata. No listed endpoint was tested.
• Claude directory and ChatGPT directory, November 7, 18:25 to 18:41, with additional consumer entries at 18:53 to 18:55: supplied browser observations identifying organization candidates. A listing shows observed publication. It does not show endorsement or a successful transaction.
• Glama public catalog, November 7, 21:14:39, and mcptry public catalog, 21:14:44: contextual directory reads, outside the selection counts.
• Positive examples: Meow Apps home page, 21:13:29, and connection guide, 21:13:31; HubSpot connector page, 21:17:10; a one-person retail-media measurement consultancy's home page, 21:22:16, and privacy page, 21:22:18 (not named or linked because it is a sole trader); Shorty privacy, 21:26:26, and llms.txt, 21:26:30. All read November 7; these support only the named positive observations.
• W3C WAI preliminary accessibility checks, November 7, 21:06:42: the scope and limits of an initial accessibility review.
• Google SEO Starter Guide, November 7, 21:06:44: useful pages and search fundamentals.
• Google Search documentation updates, November 7, 21:06:47: FAQ rich results removed; June 15 clarification that llms.txt does not change Google Search visibility or rankings.
• Google-Extended documentation, November 7, 21:06:49: the policy token's scope and distinction from Search.
• Schema.org LocalBusiness, November 7, 21:11:41, and FAQPage, 21:11:43: vocabulary only; it guarantees no eligibility, display or citation.
• llms.txt proposal, November 7, 21:06:53: the optional document convention and format.
• RFC 9116, November 7, 21:06:56, and RFC 9309, 21:06:58: security-contact files and robots rules.
• OWASP Secure Headers Project, November 7, 21:12:40: header purposes and configuration considerations. Header presence was measured; effectiveness was not established.

The kit's examples and figure are original. No third-party project code was copied, installed or run. We verified no commercial prices and make no revenue, approval or ranking promises. The publication checks cover syntax and presentation; they do not turn this study into a full accessibility, security or connector audit.

This post is informational, not legal advice. Mentions of third parties are nominative fair use. No affiliation or endorsement is implied.