Complete the case study

Open access to documentation and clarify SaaS product information

Oura Works

7 minute read

Illustration of the SaaS approach: documentation, changelog, and pricing information are organized along with crawler access, indexation, and performance checks.

Technical documentation and marketing pages need to be discoverable and explain the product consistently.

This story refers to an anonymous engagement published by Oura. The analysis, decision matrix, illustrations, and checklist below are editorial implementation guidelines; not copies of client documents or additional unattested results.

Summary of work and evidence

Aspect	Publication summary
Sector	B2B SaaS
Period	3 months
Initial conditions	SaaS businesses already have paying customers, but acquisition is still dominated by outbound and referrals. Crawler access to documentation is limited by technical configuration.
Jobs	The audit reviews robots, sitemap, indexation, and performance. Priority documentation, changelogs, and pricing FAQs are organized with consistent product identity and reference measurements.
Results reported	The case publication noted the PageSpeed score increased from 58 to 88 in three months. The foundation of product access and information becomes the focus before adding content production.
Evidence label	Measurable impact, following Oura publication

Oura engagement source. Raw data and all test conditions are not available in the public summary. These results need to be read with the initial period and conditions; is not an estimate of results for other businesses.

A good product still requires achievable public documentation

SaaS buyers don't just read the benefits on the homepage. The technical team can look for integration paths, functionality limits, version changes, and cost implications before agreeing to a demo. If public documentation is difficult to achieve, marketing pages are not always sufficient to address the need.

This case states that crawler access to documentation is limited by technical configuration, while acquisition is dominated by outbound and referrals. The priority is reviewing the foundation of access and consistency of product information. Opening more content doesn't mean the entire internal area has to become public.

Separate information that helps with evaluation from customer data, credentials, and internal records. Robots.txt directs crawler access; The file does not provide security for confidential data. Private areas require appropriate access controls on the system.

Public documentation is separated from internal areas with consistent product identity. — Example of SaaS information classification. The panel is not the client's documentation or security configuration.

Inventory example before opening documentation access

Information group	Buyer needs	Controls that need to be checked
Public guide	Understand the function and how to start	Access, versions, and page relationships
Integration documentation	Assess technical suitability	Public coverage and engineering review
Changelog	Understand product changes	Date, version, and user impact
Price FAQs	Understand plan limits and fees	Commercial approval and consistency
Customer and internal areas	Manage private data or activities	Authentication and authorization, not just robots

Use this inventory as audit material, not a copy-ready configuration list. Publication decisions need to be reviewed by product owners and engineering. Don't include API keys, sample customer data, or sensitive details in illustrations or public pages.

Access, indexation, and ranking are different checks

Pages that visitors can load may not necessarily be processed by crawlers. On the other hand, pages that can be crawled may not necessarily be indexed or have good search positions. The inspection needs to look at URL status, server response, crawl rules, indexation directives, and available content.

Sitemaps help convey the URLs that search engines want to recognize, but they don't guarantee they will all be indexed. Choose a URL that is worthy of being a public destination and is consistent with the website structure. Avoid entering private areas or URLs that conflict with publishing decisions.

Documentation needs to be understandable without relying on interactions that hide core information. If an example or guide requires a specific version, describe that version in the body of the page. It will be difficult for buyers to assess suitability if marketing materials and documentation use different terms.

The offer and proof pages are structured with a path to the reader's needs. — Example of planning page roles before structuring documentation. This is not the client's SaaS product navigation structure.

Product information requires owners and reviews

Achievable but outdated documentation can still be misleading. Determine who checks functions, examples, and package changes. Note the review date and relationship to the product version so that changes are not only visible in the changelog.

The pricing page should explain what's included, what's restricted, and when potential customers need to contact the team. Don't turn product limits into business outcome claims. Available integrations also need to be differentiated from integrations that still require special work.

In the change cycle, use clear briefs, reviews, staging and handover. Check the links from the documentation to the offer as well as from the offer to the technical explanation. These points are often the pieces read together by business and technical teams.

Briefing, review, staging, and handover form a reviewable change flow. — Example of product information change control. The images do not imply that any particular portal or process is available to the client.

Reads a score of 58 to 88 without mixing indicators

The case publication noted PageSpeed increased from 58 to 88 in three months. The scores are reported test results, not demo conversion increases and not security level percentages.

Compare URLs, simulation devices, times, and test conditions. For real user experience, read field data when available. For search access, use appropriate indexation checks. For commercial benefits, follow inquiries and opportunities received by sales.

Indicator	Purpose of reading	It cannot be proven by itself
PageSpeed	Discover lab performance bottlenecks	Overall user experience and revenue
Indexation status	Check URL suitability in searches	AI ranking or citations
Documentation visit	Understand the material read	Readiness to buy
Demo received by sales	Assess incoming needs	Contract success without follow-up

Public sources have indexation details that cannot be fully reconciled from the summary. This article chooses contextual performance figures and does not add total indexed pages as a new claim.

Image, script, and cache audits are used to prioritize performance improvements. — Example of a technical audit. The status in the image is not a record of the PageSpeed SaaS changes in the case.

What does AI-ready mean in the context of this work?

The term is useful when referring to a verifiable foundation: accessible public information, consistent product identity, answers helpful to readers, and clear evidence and sources. The term should not be a promise that AI will recommend products.

Google's current guidelines state SEO practices remain relevant for AI search features. Google does not require llms.txt files or AI-specific markup to appear in the feature. Other AI services' policies may differ and need to be checked in their respective documentation.

If the team monitors citations, note the query, platform, date, and referral URL. Continue reading to an identifiable path of demonstration or inquiry. Buyer questions coming into sales can help assess whether the documentation truly addresses needs.

Website forms are forwarded to CRM and sales while analytical events are recorded separately. — Example of a demo or inquiry measurement path. The fictitious entries in the illustration are not user data for the client's product.

Checklist for product and marketing teams

Classify public and private material before changing crawler access.
Note the documentation owner, product version, and review process.
Check access, indexation, performance, and inquiry as separate indicators.
Align functional limits and prices with the information on the marketing page.
Use sample materials that do not contain customer credentials or data.

Discuss the foundations of a SaaS website with Oura. Bring examples of public documentation, internal information boundaries, and demo routes used so that the audit has a clear scope.

FAQs

Is robots.txt enough to protect private documentation?

No. Robots.txt directs crawler access and is not an authentication mechanism. Private material needs appropriate access controls. Before opening documentation, classify the content with engineering and data owners.

Does the sitemap guarantee that all documentation is indexed?

No. Sitemaps help convey URLs, but indexation decisions are influenced by page conditions and search engines. Check the status of priority URLs and consistency of technical rules without promising that the entire page will be indexed.

Is llms.txt mandatory to appear in Google AI searches?

Not according to Google guidelines checked when this article was updated. Focus on access, helpful content, and basic SEO. Don't generalize Google policies to all AI services without checking the documentation.

Does a score of 88 indicate an improving demo?

No. Performance scores are indicators of lab testing. Valid demos, sales opportunities, and contracts require different process notes. The case summary does not provide sufficient data to conclude a causal relationship.

Which documentation should be prioritized?

Select material that helps product evaluation and can be safely published: functionality, relevant integrations, usage limits, and version changes. Priority is based on buyer questions and source readiness, not just the number of pages.