Set up Optiview from first page to live delivery.

For your first setup, start with one public page.

Not the person who manages your website? Choose Send setup to my web team in the dashboard’s ownership or Connection section. Copy the domain-specific checklist or open an email draft. Nothing is sent automatically, and the message contains no credentials or access grant. Your workspace admin coordinates authorized access; never share an admin key.

1. Add and verify the hostname.
2. Preview one public page and add approved product details, FAQs or supporting content.
3. Save and review the combined source.
4. Complete the recommended connection and immediately test normal website behavior.
5. Publish the reviewed version.
6. Test normal HTML and eligible Markdown delivery.
7. Test failure and rollback before expanding the rollout.

Optiview does not replace your CMS or bypass your security. It gives you a separate machine-readable source that your team controls.

1. Website HTML
2. Optiview extraction into clean Markdown
3. Approved, path-matched brand content
4. Versioned publication
5. Optiview edge or your server/CDN

Public Website Preview shows extracted content and may generate an unreviewed example. Dashboard Content Preview uses your saved draft. Your connected website serves the published version. Check the published result after release; a preview is not proof of live delivery.

Access is provisioned for the private beta. Contact us if your organization does not yet have a workspace. Submitting the interest form saves your request and alerts hello@optiview.ai. It does not automatically create an account, issue a key, or activate billing. Sign in at app.optiview.ai using your email and personal access key. Store access credentials in your password manager; do not share them in integration code.

An admin uses the team area to create an invitation link, choose the role, and assign domains for a strategist. Invitations expire after seven days and are single-use. Share the link privately with the invited person. Admins can revoke invitations and member access. Dashboard sessions expire; signing in again is separate from rotating a domain API key.

• Business owner: approves factual claims and the scope of publication.
• Strategist: maps content to paths and reviews draft/output accuracy.
• Web or CDN engineer: integrates delivery, secrets, fallback, and cache behavior.
• Security owner: approves source access, public-page exclusions, and any narrowly scoped security changes.
• Workspace admin: owns credentials, domain configuration, access reviews, and escalation.

• Identify the canonical HTTPS hostname. www.your-domain.com and your-domain.com are different domains for verification and API access. Choose the hostname that serves the final page without a redirect.
• Inventory page types: homepage, category, product, pricing, documentation, article, and policy pages. Include JavaScript-heavy pages, tables, variants, and legal qualifications.
• Identify your CMS, hosting provider, CDN, existing Worker/middleware, and the team that controls them. A CMS theme editor alone may be insufficient for server-side integration.
• Decide which pages are public and nonpersonalized. Exclude accounts, checkout, admin, authenticated content, private previews, and pages containing personal information.
• Choose a content approver, integration owner, and rollback owner. Keep a record of the current origin and routing configuration.
• Determine whether initial HTML contains the content. If JavaScript is necessary, assess browser rendering or server-supplied, already-rendered HTML.

Add a hostname, not an individual URL. Once a domain exists, target individual URLs through page paths in brand rules, Content Preview, publications, and Render API requests. Do not create a separate domain for each product page.

1. In the workspace overview, select Add domain. The Add your website dialog asks for the exact hostname, such as www.example.com. Leave out https://, paths, ports and wildcards. Click Continue to verification; this does not connect traffic or change DNS.
2. Use the generated ownership challenge. Select DNS TXT, HTML Meta Tag, or File Upload (.well-known). Copy the values exactly from the dashboard.
3. Install one proof, then click Verify Ownership. A challenge expires after seven days; checks are limited to one every 15 seconds.
4. After verification, open Website Setup / Connection. Keep the proof in place: connection and provisioning operations may check it again.

Option A — DNS TXT

Create a TXT record at the displayed name, normally _optiview.www.your-domain.com for www.your-domain.com. The value begins with optiview-verification= and contains a unique challenge. DNS consoles may automatically append the zone name; avoid entering it twice. This is a proof record, not a traffic-routing record. Allow DNS propagation and check the exact hostname.

Option B — homepage meta tag

<meta name="optiview-verification" content="COPY_THE_ENTIRE_DASHBOARD_VALUE" />

Place exactly one matching tag in the homepage’s server-rendered HTML <head>. The verifier fetches https://YOUR_HOSTNAME/ and requires a direct 200 HTML response. It does not execute JavaScript or follow redirects. Inspect the initial HTML, not only the browser’s live DOM. A tag inserted after hydration will not verify.

Option C — public text file

https://YOUR_HOSTNAME/.well-known/optiview-verification.txt

File contents: the entire TXT record value shown in the dashboard

Serve the exact value as a public text file over HTTPS with a direct 200 response. The path is optiview-verification.txt, not optiview.txt. Do not wrap the value in HTML. HTTP proof requires a public DNS resolution and a valid HTTPS endpoint. A redirect from apex to www means you should register and verify www instead.

A hostname already registered to another workspace cannot be claimed again. Ask the workspace operator to reconcile an authorized transfer. Successful verification proves control; it does not change DNS, create a route, bypass a firewall, or publish content.

Open Website Setup / Connection. Verified sites awaiting setup are checked automatically; Check my website repeats the check. Optiview inspects the public page, DNS and available Cloudflare authorization without changing your site. It recommends an authorized route, guides you through DNS setup, or asks for a hosting review. You do not need to select an integration before running this check.

Private-beta setup is assisted. Automated DNS-provider onboarding is not generally available; provider template validation remains separate from manual connection testing. Shopify storefronts require a reviewed integration, and automatic proxy setup is not supported. Keep existing DNS unchanged until the supported method is agreed.

DNS changes are manual during private beta. You or your domain administrator add or update the records shown in the dashboard. Send setup to my web team lets marketing hand over that work. Optiview checks the connection afterward.

For API integration, DNS can stay as it is. You still need engineering access to a server or CDN that can call the API and deliver the response. An API key or ownership meta tag alone does not place Optiview into the request path. Do not make a CNAME change merely because a certificate becomes active.

Guided DNS connection — customer steps

1. After the hosting check recommends Guided DNS connection, review the tested hosting destination. If it cannot be validated, setup stays in hosting review and does not supply traffic changes. Enable Load JavaScript before extraction if important content requires JavaScript.
2. Confirm the tested HTTPS hosting hostname. Do not enter the public hostname being connected or a Cloudflare proxy IP. Save the original DNS record for rollback.
3. Click Prepare connection. Optiview tests the hosting destination and forwarded HTML, checks published Markdown through the gateway, then requests the hostname certificate. Preparation does not change customer DNS.
4. Add the displayed hostname ownership TXT and certificate verification records. When a delegated certificate CNAME is supplied, keep it DNS-only. Do not replace the website traffic record yet. Keep the Optiview ownership proof and certificate delegation records in place.
5. After the certificate and origin checks pass, the dashboard displays the traffic CNAME to proxy.optiview.ai. Replace only the website record for the exact hostname. For Cloudflare DNS, keep the traffic CNAME Proxied to retain the customer zone in the request path. Root domains require CNAME flattening; otherwise use a supported www hostname or a Custom API integration.
6. Optiview checks pending connections every five minutes for up to 48 hours. It observes the real public route, checks HTML, and tests published Markdown before marking Connected. The open dashboard refreshes status automatically. Check connection now is also available. If the 48-hour window expires, finish your DNS changes and click Restart automatic checks. You do not need to keep the dashboard open.
7. Preview the homepage and important internal pages, save and review brand content, then publish. Test forms, login, redirects, cookies and assets before treating the production cutover as complete.

DNS changes are still made by you or your web team. Optiview does not sign in to your DNS provider or edit its records. The number of records depends on ownership and HTTPS validation; this is not a universal one-record setup. Hosting detection is a preliminary check, not a guarantee of compatibility. Connection preparation and live checks still run before activation.

1. Confirm the exact hostname is verified, its existing A/AAAA/CNAME record is proxied through Cloudflare, and the zone belongs to the configured delegated account.
2. Open Website Setup / Connection / Authorize Cloudflare access. Click Check Cloudflare access to test the existing workspace token. If access is missing, expand Authorize this website with a scoped token.
3. Create a Cloudflare API token with Zone Read, DNS Read and Workers Routes Edit, limited to Include / Specific zone for this website. Enter the Zone ID and token in the secure admin form, then click Validate & save authorization. Tokens are encrypted server-side and never returned. Do not paste tokens into page content or client-side application code.
4. Check for overlapping Worker routes and confirm the origin is healthy. Resolve conflicts with the route owner before changing routing.
5. After access checks pass, click Connect Route. Read-only access checks confirm zone, DNS and route visibility; Cloudflare checks route-write permission during connection. Connecting creates or reconciles the hostname/* Worker route without changing DNS records or security rules.
6. Publish approved content and run the HTML/Markdown checks in this guide. Inspect real origin behavior and security logs before expanding the rollout.

A verified domain in a different Cloudflare account is not automatically eligible for this delegated route. Use guided DNS connection when the hosting origin is compatible, or the Custom API integration. If you specifically need a delegated route, ask the operator to configure account access. Do not broaden token access just to suppress a connection error.

Use Disconnect Route to remove the managed route while retaining drafts. If route ownership changed or cleanup failed, stop and ask the operator to reconcile it. Do not delete unrelated Workers or routes. Retest ordinary HTML after disconnecting.

To rotate access, replace the saved token in the same form. To remove it, disconnect the managed route first, remove the saved credential, and revoke the unused token in Cloudflare. Removing a domain credential does not remove any separate workspace-level authorization. The route token cannot grant itself more zone permissions.

Optiview APIs are available. Contact us to discuss access, your hosting setup and integration requirements. We’ll provide the technical documentation for your use case.

Open Website Setup / Advanced Settings to review the main content selector and additional frontmatter. The generated domain configuration starts with main, article, .content; extraction also has fallback behavior. Test your selector on each page type. A selector that targets only a description can omit prices, product variants, taxonomy, or qualifications elsewhere on the page.

Extraction preserves meaningful source content, structure and link occurrences where supported. A separate deterministic composition pass reduces repeated directory groups to compact links. It does not generate missing descriptions or fetch linked pages. Distinct groups and unequal memberships stay separate; ambiguous composition keeps the original representation. Compare facts, prices, units, conditions, table relationships and destinations with the received source, not just the output length.

In Website Setup / Connection / How Optiview reads this website, an admin can enable Load JavaScript before extraction. This setting is stored independently of the draft and changes rendering/cache behavior immediately. Public rendered pages can be cached for up to 15 minutes; publication and rendering-setting changes invalidate the relevant Optiview cache version. Browser work consumes a separate budget.

Browser rendering is bounded and restricts resources. Cross-origin dependencies, login flows, challenges, canvas content, and some component architectures may remain incomplete. Rendering is not a WAF bypass. For controlled applications, supplying already-rendered HTML can be a better integration than depending on an external browser.

See Evidence & methodology for the reviewed parser/composition baseline and recorded validation scope. The public demo, previews and delivery share the composition layer; acquisition settings and source responses can still differ. Evidence-enabled results retain original compiler Markdown and the occurrence inventory in source_composition; ordinary delivery does not carry the full duplicate inventory.

From an AI suggestion to published content

The public demo can draft a source-supported answer for eligible previews. This is separate from deterministic extraction and composition. Demo suggestions and local edits are not automatically saved, approved or transferred. For supported original answers, you can download a review package and explicitly import it into a verified website’s workspace within 15 minutes.

1. Inspect the original answer and its cited passages. Confirm the facts and preserve qualifications; AI-assessed support is not independent verification.
2. For an imported suggestion, save edits, inspect its exact question, answer, evidence and path, acknowledge your review and select Add to content draft. This stages a Questions & Answers block locally without saving or publishing. Existing conflicting answers require manual resolution. You can also add reviewed text manually.
3. Save the draft and preview the combined source. Your organization manages factual approval; the product does not require a separate approval role.
4. An authorized admin or assigned strategist publishes the reviewed version. Check the published preview and live delivery. Exact-source review remains separate when required.

Local demo edits are not re-evaluated. Under Added Content, import a review package into Evidence-backed suggestion drafts with an exact destination path. This retains the original cited evidence separately from editable text for 90 days. Editing requires fresh human review, even if you revert the text. Saving a suggestion does not add it to the published source; use the deliberate Added Content steps above. The guided handoff requires a saved-draft preview for the current version and exact path before its publication confirmation. That confirmation includes all applicable saved content, not just the FAQ. No model generates a new FAQ simply because a crawler requests the page.

Brand Details

Open Brand Content / Brand Details and add a schema. The form builder supports Organization, Product, and FAQPage. Choose a Page path before filling the fields. The form compiles JSON-LD; customers do not need to hand-edit JSON.

Approved facts are entered one per line. A domain supports up to 30 schemas and 30 content blocks. The current form is not a general-purpose multi-entity graph editor: do not paste an arbitrary @graph or assume Book/SoftwareApplication templates exist.

Added Content

Open Brand Content / Added Content. Choose the page path, content type, and placement before or after page content. Supported types are FAQ_BLOCK, SITELINK_BLOCK, and COMPETITOR_TABLE. The body accepts Markdown, up to 50,000 characters per block. Use headings, lists, or tables when they improve clarity; ordinary short paragraphs are fine.

Use FAQ_BLOCK for questions and answers, SITELINK_BLOCK for curated destinations, and COMPETITOR_TABLE for supported comparisons. The category does not verify a claim. Do not invent certifications, testimonials, guarantees, warranty terms, or comparative superiority. Maintain an approval owner and source evidence for every material claim. Comparison content should use current, verifiable public information and follow your organization’s legal and editorial review requirements.

Path targeting

Rules can overlap; check that global and page-specific blocks do not repeat or contradict each other. Content rules may use section wildcards, while publication scope supports only all pages or one exact path.

Open Website Setup / Page Guide (llms.txt) to author a plain-text/Markdown roadmap to important public pages. Include accurate titles, URLs, and short descriptions. Save and publish it with the all-pages release when updating the domain-wide guide. On a connected edge route, /llms.txt is served as plain text, separately from page conversion.

# Your organization
> A factual one-sentence description.

## Public resources
- [Product](https://www.your-domain.com/product/): Approved product information.
- [Documentation](https://www.your-domain.com/docs/): Technical integration details.
- [Policies](https://www.your-domain.com/policies/): Published policies and conditions.

An API-only integration does not automatically create a public /llms.txt endpoint on your site. Your team must serve it through its own infrastructure if desired. The file is a guide, not an enforceable instruction to crawlers or a replacement for robots.txt.

Advanced frontmatter is structured metadata saved with the draft. Keep JSON syntax valid in the editor. Delivered Markdown includes the source URL, content type, publication version, publication time when available, and whether brand content is included. The publication time identifies the approved-content snapshot; website content is fetched separately and can change afterward. Parser version, pruning mode and rendering state are available in API extraction metadata and delivery headers. Draft previews are marked unpublished. Engine-owned provenance fields cannot be overridden by custom metadata.

1. Complete edits and click Save changes. The unsaved indicator applies to the domain draft across tabs. Confirm it clears and note the draft version.
2. Open Content Preview, enter an exact Page path such as /, and run the preview. Preview uses the saved draft, not unsaved form text.
3. Check the main content, headings, product facts, links, table labels, price footnotes, schema, and all matching added blocks. Resolve partial-content warnings before approving the page.
4. Select publication scope: /* for all pages or a single exact path such as /product/. Click Publish updates.
5. If the source says Review required, select Published version in Content Preview and run a new preview after publishing. Inspect the evidence, confirm the review checkbox and choose Approve this page source. Draft preview is not source approval. Approval is limited to the exact page, source, extraction settings and published content version; relevant changes require a new review. Source unavailable must be resolved before Markdown delivery.
6. Fetch through the deployed edge or Render API, record publication_version and payload_sha256 when available, and compare the delivered content with your approval.

Ownership verification unlocks dashboard Content Preview before connection, including optional JavaScript rendering. Preview fetches only public content without visitor credentials. Cookie or cache restrictions may limit live delivery even when preview works. API-only sites can preview here and test delivery separately through their server integration.

Saving increments the draft version. If someone else saves or a partner submits a suggestion, stale saves and publications can return a conflict. Reload, review the latest changes, and reapply your edits rather than overwriting them blindly.

An exact-path publication pins a snapshot for that path. Other paths continue using the global publication. Publishing all pages replaces the global snapshot and clears exact-path overrides. Plan this carefully when different product pages are on different approved releases. Publishing selects a new cache version for subsequent requests; it does not alter responses already delivered.

Rollback: restore the previously approved content into a draft, save, review, and publish the required scope. Publication history supports inspection; there is no documented one-click rollback workflow. For urgent delivery withdrawal, disconnect the managed route or disable your own adapter and serve origin HTML. Revoking a render key stops API delivery for that key; it does not disconnect an independent edge route.

Before connecting, verify ownership, confirm the hosting destination and keep a rollback record of your current DNS or route. Connection changes the delivery path; test normal website behavior immediately afterward. You can save and preview approved content after ownership verification, before connecting. Publish the reviewed version and complete these delivery checks after connection, before expanding the rollout. Record the URL, source mode, time, publication version and delivered result. Record parser and composition versions from response metadata or, on the connected edge, x-optiview-parser and x-optiview-composition headers.

These checks let your team independently verify what Optiview is — and is not — serving. A successful response alone is insufficient: inspect the response format, headers and actual content. These tests verify delivery, not indexing, citation or AI outcomes.

# Ordinary visitor: inspect status, content type, and actual HTML body.
curl -sS -D human-headers.txt 'https://www.your-domain.com/product/' -o human.html

# A crawler name alone must not trigger Markdown.
curl -sS -A 'GPTBot/1.0' -D ua-headers.txt \
  'https://www.your-domain.com/product/' -o ua-response.html

# Explicit content negotiation through the installed adapter/route.
curl -sS -H 'Accept: text/markdown' -D markdown-headers.txt \
  'https://www.your-domain.com/product/' -o delivered.md

# Connected edge Page Guide.
curl -sS -D guide-headers.txt 'https://www.your-domain.com/llms.txt' -o llms.txt

• Human and User-Agent-only requests retain normal HTML. A forged crawler name may separately be rejected by your security layer; that is not proof of Optiview routing behavior.
• An eligible Markdown request returns text/markdown and the expected published content. An API-only deployment needs your adapter installed before this test can pass at the website URL.
• Assert factual retention: product names, prices and currencies, variants, meaningful category links, technical tables, and qualifiers. Check for placeholder text, UI controls, duplicate blocks, and malformed links.
• Inspect source-review status. A flagged source needs exact-source approval for delivery; publication alone is insufficient. Compare composed links with the original occurrence inventory when evidence is available. Repeated groups may be compacted, but destinations and source qualifications must remain represented.
• Check homepage, deep product, category, documentation/article, and policy pages where applicable. Test trailing slashes and exact-path versus global publication.
• Confirm private/cookie-bearing routes are excluded and no sensitive data enters payloads or logs. Verify cache variants cannot mix HTML with Markdown or one customer with another.
• After an approved content update, confirm a new publication version and the changed content. Confirm your own CDN cache refreshes too.
• Verify telemetry appears in the expected API or proxy channel. Preview traffic must not be used as evidence of organic crawler adoption.

The domain Overview shows successful API and proxy deliveries across 30 calendar days in UTC. Preview and public demo activity are excluded from that chart. Queued telemetry can take a few seconds to appear. Delivery Telemetry & Usage provides operational usage; estimates and configured cost assumptions are not your Cloudflare invoice.

Current private-beta limits — reviewed October 6, 2026

These are implementation limits for the private beta, not a contracted capacity or SLA. Confirm capacity with the operator before a launch, automated bulk test, or customer rollout. Do not rotate keys to evade quotas. Retry transient failures with bounded backoff and keep your origin fallback active.

Monitor extraction failures, partial content, latency, delivery counts, budget use, and stale publications. Recheck representative pages after CMS/theme releases. Review teammate access and key owners regularly. If service eligibility is paused, optimization/publishing can stop while drafts and history remain accessible; the edge falls back to origin. Customer-managed adapters must implement their own fallback.

A client-side shell can benefit from rendering if content is available to the bounded browser. A security denial needs authorized access or supplied HTML. No extraction mode automatically defeats your firewall. Avoid removing security controls broadly; diagnose the exact rule and request first.

• Treat ownership proof, dashboard access, render credentials, and partner credentials as separate controls. Use least privilege and exact-host scope.
• Only submit content you are authorized to process. Strip personal, authenticated, confidential, and personalized information before Push ingestion.
• Keep existing robots, authentication, and WAF decisions under your team’s control. Content negotiation is not authentication and is available to any compatible requester.
• If a security exception is necessary, have your security team inspect the actual blocking component and use narrowly scoped rules. Do not allowlist a crawler solely by its User-Agent string.
• Review provider processing, retention, and your organization’s requirements before sending source content. The private beta should not be assumed to meet an unprovided certification, data residency requirement, or contractual SLA.
• Never include tokens, customer records, or private HTML when escalating an issue. Supply a sanitized URL/path, timestamp, status, source mode, publication version, and redacted error instead.

See the Privacy Policy and Evidence & methodology for public boundaries. Content availability and delivery can be tested; better AI answers, indexing, and citations require separate evidence. There is no guarantee that a named crawler requests Markdown or uses any delivered payload.

• Record the workspace, exact hostname, integration mode, public-path allowlist, and responsible business/technical owners.
• Store keys in your secret manager, record rotation ownership, and remove temporary credentials from local test files.
• Attach approved content, source evidence, publication version, and representative before/after payload checks to your internal release record.
• Document timeouts, quota handling, cache invalidation, private-route exclusions, and the tested origin fallback.
• Assign monitoring and an escalation owner. Schedule content review after material pricing, policy, product, or CMS changes.
• Document how to disable your adapter or disconnect the managed route, plus the origin checks to run afterward.

During the private beta, use your established Optiview onboarding contact or workspace operator for provisioning and incident escalation. If you do not have one, contact us. Provide sanitized reproduction steps and observed responses; do not send credentials. Private-beta capabilities, limits and supported integrations may change as the platform develops.

Open the dashboard · API access · Frequently asked questions