Where your intake data lives, and who can see it.

Two surfaces, both customer-initiated. Nothing happens until you submit a form.

The marketing site (web-cited.com). Cookieless aggregate analytics via Plausible: anonymous page-view counts, referrer source, and country-level geography (derived from a daily-rotating hash). No IP retention. No tracking cookies. No cross-site identifier. No fingerprinting. No advertising scripts. We do not see individual visitor identities, persistent sessions, or browsing across the open web. The only thing the site writes to your browser is a single local-storage key (wc-notice-dismissed-v1) that remembers you closed the privacy notice. That key never leaves your browser and is never transmitted to us.

The intake form at /start. The fields you fill in are submitted to our own API at api.web-cited.com:

• Contact: first and last name, work email.
• Company: company name and website.
• Audit scope: the primary market you serve, whether you have a storefront or service area, a short business description, the buyer questions you want us to test across the engines, and your competitor list.
• Tier and consent: the audit tier you've selected (SXO Audit or Enterprise) and your explicit acknowledgment of our scope and consent language.

The contact form at /contact. The same API endpoint receives your name, email, subject category, and message body. Nothing else.

We do not have an upload widget. The only files that ever move into our systems are the ones we generate during an audit (your report PDF, your Playbook, your Schema Pack) - we do not accept arbitrary file uploads from customers.

Marketing site - Cloudflare Pages. The static HTML, CSS, JavaScript, and images at web-cited.com are served by Cloudflare Pages through Cloudflare's global edge network. DNS for web-cited.com is also provided by Cloudflare. Cloudflare may retain access logs (including IP addresses and request headers) at the infrastructure level for security and content delivery; Web Cited does not access, request, or retrieve those infrastructure logs.

Intake API - Cloudflare Workers. The endpoint at api.web-cited.com that receives intake and contact submissions runs on Cloudflare's edge-compute platform. At-rest operational data for the intake API (the submission record, scope notes, and audit-trail metadata) is stored on Cloudflare's storage backends, encrypted at rest and in transit (TLS terminating at Cloudflare's edge).

Audit pipeline - Railway. The audit pipeline at audit.web-cited.com runs on Railway, a managed application hosting platform. Railway executes the audit and stores intermediate audit state (your submitted URLs, buyer questions, and per-engine LLM responses) during processing. Railway may retain access logs at the infrastructure level under its own privacy policy.

CRM and email transit. Your contact record and deal record live in HubSpot. Transactional emails (scope confirmation, kickoff, follow-up) are sent through Resend on a verified Web Cited sub-domain. Invoices and hosted checkout run through Stripe; Web Cited never sees your card data.

Cookieless analytics, no identity tracking, no fingerprinting. The marketing site loads exactly one third-party script on page load: Plausible (cookieless aggregate analytics from plausible.io; no IP retention; no cross-site identifier). Every other asset is served from web-cited.com itself. There is no Google Analytics, no Mixpanel, no Segment, no Heap, no Fathom, no server-side identity correlation, no chat widget, no embedded video, no marketing pixel, and no fingerprinting library.

Web Cited personnel. Aliso LLC dba Web Cited personnel with engagement scope. Today this is the founder. Access to the intake API, CRM, and audit pipeline is via per-platform consoles with two-factor authentication.

Subprocessors. The current subprocessor list mirrors Terms of Service §6.7 and our Privacy Policy:

Personal-data processors (handle your contact details, company information, and payment information):

• Cloudflare - marketing site (Pages), intake API (Workers), and at-rest operational storage.
• HubSpot - CRM holding your contact and deal records.
• Resend - transactional email delivery for scope, kickoff, and follow-up emails.
• Stripe - payment processor for invoices and hosted checkout. Web Cited never sees your card data.

Audit-content backends (process your Customer Content - buyer questions, brand and competitor list, URLs; do not directly receive your name, email, or other contact details):

• Railway - managed hosting that runs the audit pipeline and stores intermediate audit state during processing.
• OpenAI, Anthropic, Google (Gemini), Perplexity, xAI (Grok), and DeepSeek - LLM backends queried with your buyer questions to test how each engine answers. DeepSeek's default endpoint is hosted in mainland China; customers can opt out of DeepSeek at intake (remaining five engines run as normal, pricing unaffected).
• DataForSEO - structured search-engine and SERP data provider.

Each provider acts as a data processor under our instructions and is governed by its own privacy policy and our data-processing agreement with it. The authoritative current list is in our Privacy Policy.

The two public forms - intake at web-cited.com/start and contact at web-cited.com/contact - both POST to api.web-cited.com. The defense layers, in the order they fire, are:

1. Cloudflare platform protection. Every request to the Worker passes through Cloudflare's default DDoS, WAF, and bot-management edge. This is the first filter and the only one that operates at network scale.
2. Strict Content Security Policy on the form-bearing pages. The site-wide CSP includes form-action 'self' https://api.web-cited.com, which prevents any cross-site script from redirecting form submissions to a different endpoint. The same CSP disallows 'unsafe-inline' and 'unsafe-eval', blocking the most common XSS vectors that would otherwise let an attacker inject a form-stealer script.
3. Honeypot field. Each form contains a hidden text input named _gotcha that is positioned off-screen and marked aria-hidden="true" so screen readers and humans never see it. Automated form fillers populate it as a matter of course; submissions where this field is non-empty are silently accepted (HTTP 200) and dropped server-side. Returning success rather than an error is intentional - it removes the signal an attacker needs to tune around the trap.
4. Page-load timestamp. A hidden ts_loaded field is set to the page-load epoch milliseconds via JavaScript. The Worker rejects submissions that arrive in less than 3 seconds after page load, which catches the common naive bot pattern of immediate-submit-on-page-fetch. As with the honeypot, the response is HTTP 200 so the attacker gets no actionable signal.
5. Server-side schema validation. The Worker validates every field on the submitted body for type, length, and shape before persisting anything. Missing required fields, oversized values, or malformed values return HTTP 400 with a generic message. There is no client-only validation path.
6. HubSpot-side unsubscribe re-check at send time. Outbound transactional and follow-up emails check the contact's outbound_unsubscribed flag in HubSpot before sending, even if the contact unsubscribed after their intake. This is reply-side defense rather than form-side, but it closes the loop on what an attacker could trigger by submitting under a stolen email.

CSRF posture. The intake and contact endpoints accept cross-origin POSTs from web-cited.com by design (the form lives on the marketing site; the handler lives on the API origin). No session cookies are issued, which means a CSRF attack would have no authentication context to leverage - the worst an attacker could trigger from a third-party site is the same unauthenticated form submit that anyone on the open internet can already make. The CSP form-action directive plus the absence of cookies makes traditional CSRF infeasible against these endpoints.

Rate limiting. The Worker does not currently apply an explicit per-IP or per-session rate limit to the intake or contact endpoints; the defense against burst submissions is the combination of Cloudflare's platform-level DDoS protection, the honeypot, the page-load-timestamp check, and the server-side validation. If we observe meaningful abuse, an explicit KV-counter rate limit (e.g. five intakes per IP per hour) is the planned next layer.

• We never train AI models on your data. Your buyer questions, competitor list, URLs, and intake content are used to produce your audit and nothing else. We do not feed your Customer Content into model training pipelines, embeddings stores, or fine-tuning datasets.
• We never sell, share, or transfer your data to third parties beyond the named subprocessors above. Not for analytics, not for marketing, not for any commercial purpose. No data brokers. No advertising partners.
• We never add you to a marketing list. Submitting the intake form or the contact form does not enroll you in a newsletter, drip sequence, or nurture campaign.
• We never run identity-level tracking on the marketing site. Aggregate page-view counts via Plausible (cookieless; no IP retention; no cross-site identifier; aggregate-only) is the only analytics. No Google Analytics, no Mixpanel, no Segment, no Heap, no Fathom, no server-side identity correlation. No ad pixels. No fingerprinting library. No third-party fonts. The site sets zero tracking cookies.
• We never transmit sensitive content through email bodies. Transactional emails contain links to documents and engagement metadata, not the underlying Customer Content.
• We never store your card data. Payment data is handled entirely by Stripe under Stripe's terms; Web Cited's systems do not see card numbers, CVCs, or expirations.
• We never publish your audit content. Public sample artifacts on the site are built from publicly available data or from customers who have explicitly approved publication; real customer Customer Content never lands in marketing assets.

Default retention periods, mirrored from our Privacy Policy. You can request earlier deletion at any time (see below).

• Intake-form data and CRM record (your contact details, company, deal record, scope notes): retained while the relationship is active and for as long as we may reasonably need it for follow-up engagements, dispute resolution, and operational records. Indefinite by default; deleted within 30 business days of a deletion request, subject to the legal-records carve-out below.
• Email correspondence (scope, kickoff, follow-up, support, ad-hoc threads): retained in Resend's logs and in our mail provider's archive while the relationship is active. Indefinite by default; deleted within 30 business days of a deletion request.
• Intake API operational data (the at-rest record on Cloudflare's storage): retained for the duration of the engagement and for normal operational purposes (debugging, audit-trail integrity, abuse prevention) thereafter. Deleted within 30 business days of a deletion request.
• Playbook URL content (Audit and Enterprise tiers): 12 months hosted at a private URL, plus 12 months in archive, then deleted at 24 months from delivery unless a separate retention agreement applies. Full schedule in Terms of Service §6.1.
• Paid invoices and tax records: 7 years, retained by Stripe and by Web Cited as required by U.S. and California tax and accounting law. We can remove your name and company from any draft, unpaid, or voided invoice on request, but cannot delete paid-invoice records during the retention period.
• Local-storage notice-dismissed key (wc-notice-dismissed-v1): set in your browser only; never transmitted to Web Cited or any third party. Persists until you clear browser site data.

Legal-records carve-out. We may retain specific records longer than the periods above where required by law (tax and accounting records, records under legal hold or active dispute resolution). The carve-out is narrow and applies only to the specific records covered.

Breach notification. If we confirm unauthorized access to, loss of, or disclosure of personal data we control, we will notify affected customers without undue delay - and in any event consistent with our obligations under applicable law. The notification will identify the nature of the incident, the data categories involved, our containment steps, and any action we recommend you take.

How to report a suspected incident or vulnerability. Use the contact form with subject "SECURITY". The form routes straight to a human inbox. We commit to acknowledging within one business day and substantively responding within five business days. Please include enough detail to reproduce the issue: affected URL, expected vs observed behavior, and any payload or steps. We do not currently operate a paid bug-bounty program but we credit responsible disclosure in any post-incident notes when the reporter requests it.

We ask that you do not publicly disclose a suspected vulnerability before we have had a reasonable opportunity to respond and remediate.

We aim to be straight about what we do and do not have today.

• SOC 2: not currently certified. If your procurement function requires SOC 2 to onboard a vendor, contact us; we can provide our subprocessor list, this security page, the privacy policy, and security questionnaire responses as an interim.
• ISO 27001: not currently certified.
• GDPR / UK GDPR: we serve a primarily US business audience but where GDPR or UK GDPR applies to a given engagement we honor the data-subject rights described in our Privacy Policy (access, rectification, deletion, portability, objection) and rely on the legal bases set out there (performance of contract, legitimate interests, legal obligation, consent).
• California privacy laws (CCPA / CPRA): we honor data-subject access and deletion requests through the process described in the Privacy Policy. We do not sell or share personal information as those terms are defined under the CCPA/CPRA.
• HIPAA: not applicable. Web Cited does not collect, store, or process Protected Health Information (PHI). Audits in regulated industries (healthcare, finance, etc.) should not include PHI or other regulated data in the intake.
• PCI DSS: Web Cited's systems do not store, process, or transmit cardholder data. All card handling is performed by Stripe, which maintains its own PCI DSS attestation.
• Governing law and entity: Web Cited is the trade name of Aliso LLC, a California limited liability company located in Orange County, California. These commitments are governed by California law, consistent with Terms of Service §15.

Three ways to confirm what is on this page.

1. Read the Terms of Service and Privacy Policy. Both are click-wrap accepted at intake and are the binding versions of the commitments above. If anything on this page differs from those documents, the legal documents govern.
2. Inspect the marketing site. Open browser devtools on any page of web-cited.com and watch the network tab: the only third-party request on page load is to plausible.io (cookieless analytics beacon, disclosed above). Every other asset is served from the same origin. No cookies are set. The single local-storage key is named wc-notice-dismissed-v1 and never leaves your browser.
3. Ask a security or procurement question. Use the contact form with subject "SECURITY" and we will respond in writing within two business days.

This page is a public commitment. We update it as our infrastructure changes; the date below shows when it was last reviewed.

Last reviewed: May 24, 2026.