What the service handles, and for how long.
See data handled for PB AI evidence, full articles, publishing credentials and releases, API/MCP access, rendering, Buddy and Ads, with retention boundaries.
On this page
Overview
Technical data overview
Prerender Buddy processes public-page and workspace data to provide website Health, crawler activity, controlled AI Visibility monitoring, full article generation, reviewed publication through configured destinations, scoped API/MCP access, Buddy/Agent assistance, optional human management and eligible AI Ads workflows. This page explains the current implementation, including minimized logs, in-memory cache behavior, product records, provider involvement, and known policy gaps.
This overview complements the Privacy Policy. It is not a data processing agreement.
Implementation reviewed: October 6, 2026.
Public page content
The renderer fetches the configured public URL, loads public page resources, and captures the resulting HTML.
Minimized render logs
Durable render logs omit query strings and fragments and keep operational fields for a limited period.
AI Visibility evidence
When configured, Prerender Buddy stores controlled prompts and provider responses, including answer text, source and citation relationships, run context, tracked brand aliases, and tracked or detected competitors. These observations come from configured provider API runs; they are not private consumer conversations.
Content, Agent, creative, and Ads records
Content workflows store full article drafts, proposals, review/approval state and the answer/source, competitor and website evidence available for generation. Buddy/Agent and support workflows process conversations and relevant account/site context to answer the request; optional human management uses relevant workspace context when that service is requested.
Publishing connections, schedules and releases
Publishing stores configured destination identifiers and mappings, encrypted CMS/GitHub credentials, deploy hooks or webhook signing secrets, private feed-key hashes, article approval state, released article snapshots, schedules, actor identifiers/contact where supplied, remote IDs/URLs, delivery attempts, errors and timestamps. Approved article content and required metadata are sent to the configured destination. WordPress, Webflow, Shopify blogs, Wix blogs and Ghost use supported draft/publication workflows; Astro releases a private feed version and requests a rebuild; Keystatic uses a GitHub content pull request and approved Git release; a publishing webhook records delivery acceptance. These are different outcomes, and hosting completion requires its own verification. Publishing destinations
Disconnecting a connector clears its stored publishing credential and feed-key hash; connection metadata, drafts and release/delivery records can remain. PB deletion flows affect PB records, not content already delivered to another system. Use destination controls for remote posts, Git commits, webhook copies and hosting artifacts.
API and MCP authorization
Account access stores API-key prefixes/hashes, OAuth authorization and token records, scopes and workspace/site associations. Connected clients receive requested evidence or content within the authorized scope and can retain their own copies. Hosted MCP generation saves an unapproved full draft; API approval, delivery and schedule actions have separate scopes/confirmations. Developer API, workspace MCP
AI Ads workflows can store uploaded or generated creative assets, copy and creative variations, proof results, provider account identifiers, encrypted provider credentials, connection state, and imported performance records such as impressions, clicks, spend, currency, and reporting dates. A saved or exported creative is not proof that an ad is live.
Storage and retention
Current application defaults.
Automated cleanup runs on a schedule. Account, site, and workspace records also follow explicit deletion flows. There is no single verified retention period for every AI Visibility, content, publishing, creative or Ads record. Raw provider-response fields can have recorded purge dates separately from normalized evidence. Support/Buddy conversations in the support store follow the default below, while usage/audit records can follow separate periods. No automatic retention period is established here for CMS connection metadata, publication schedules, release snapshots or delivery history. Provider-side copies and settings require separate confirmation.
Documented application defaults
| Record | What is retained | Default retention or boundary |
|---|---|---|
| Site and workspace configuration | Domain, origin URL, setup mode, status and cache settings | Until the site, workspace or account is deleted |
| Render logs | Origin/path without query or fragment, bounded user agent, cache result, duration, status and timestamp | 30 days by default |
| Rendered HTML cache | Public HTML, final URL, status and timestamp in gateway process memory | Configured normal-read TTL up to 7 days; periodic cleanup after the retention deadline, capacity eviction, explicit clearing or restart. Eligibility for bounded stale responses differs from memory retention. |
| Usage records | Fresh-render quantities, quota-notification records and support/Agent usage metering | 400 days by default |
| Free-tool analytics | Tool, hostname, outcome fields, source and allowlisted metadata | 90 days by default |
| User-created public reports | Public URL without credentials/query/fragment; dated metrics and issue summaries; no raw HTML or page excerpts | 90 days by default, or earlier on creator deletion |
| Product funnel analytics | Consent-based page paths and pseudonymous milestones; no tested URLs, site domains or email addresses | Configured PostHog project retention |
| Interaction analytics | Consent-based page/browser/device interactions, heatmaps and privacy-masked reconstructed recordings | Clarity playback: 30 days; labeled/favorited sessions and heatmap/click data: 9 months under its documented policy |
| Support/Buddy conversations | Messages and relevant account diagnostics in the support conversation store | 90 days by default; usage metering and audit records follow separate defaults |
| Email preferences | Opt-in, consent source/time, policy version, unsubscribe time and synchronization state | Until account deletion; opt-out state enforces the preference while the account record exists |
| Administrative audit records | Administrative action and target identifiers | 365 days by default |
| Publishing connection and release records | Configured destination metadata, encrypted secrets/feed-key hashes, approval/schedule/release and delivery state | No automatic retention period verified here; disconnect clears connection secrets/keys, and site/workspace/account deletion follows explicit PB flows |
Default periods describe Prerender Buddy application records. Provider-side backups and legal retention may follow separate terms.
Important cache detail
Logs and cache treat URLs differently.
Durable render logs remove query strings and fragments before storage. The process-local HTML cache currently uses the exact requested URL as its key, so query parameters can produce separate cached entries.
Do not place credentials, session identifiers, personal data, signed private resources, or sensitive state in URLs sent through crawler rendering. Keep personalized and authenticated pages outside the render path.
The gateway HTML cache is not durable or shared across renderer instances. Entries leave through periodic retention cleanup, capacity eviction, explicit clearing or process restart. Dedicated workers return render results through the queue rather than retaining a duplicate local HTML cache; queue/result transport is separate from this gateway cache.
After confirmed publication through a supported native WordPress, Webflow, Shopify blog, Wix blog or Ghost connector, the API attempts to clear the registered site's renderer cache. This is best-effort and separate from customer/CDN/browser caches. Off-platform edits, Astro feed releases, Keystatic Git releases and webhook delivery do not establish the same live-publication event. Verify hosting and the crawler-visible result, then use the appropriate purge/refresh path. Failure and fallback behavior
Service providers
Systems visible in the implementation.
This functional inventory links to current provider documentation. A provider may act as a processor, subprocessor or independent controller depending on the service and data involved. Customer-configured CMS, GitHub, webhook and hosting destinations also receive approved content and required metadata; these customer connections are distinct from the PB infrastructure inventory. API/MCP client copies and destination records follow their own terms and deletion controls.
Clerk
Identity and authenticated sessions
Railway
API, rendering service, PostgreSQL, and application records
Cloudflare
Managed custom hostnames, DNS and HTTPS validation, and edge forwarding
Netlify
Public website, functions, and maintained edge integration
Stripe
Hosted checkout, subscription billing, invoices, and payment administration
Resend
Transactional email, support escalation, and consented marketing email delivery
Hostinger
Support and business email mailbox hosting
OpenAI
AI Visibility, Buddy/Agent, support assistance and applicable article/creative generation when those features are used
Other enabled AI-answer providers
The deployed adapters also support Anthropic, Perplexity, Google Gemini, xAI/Grok and Meta AI/Muse. Relevant prompts/context are sent as the configured and enabled features run. Each provider has its own processing, terms and retention settings; no single provider policy is applied to all of them here.
PostHog Cloud US
Consent-based web analytics and pseudonymous product-funnel milestones
Microsoft Clarity
Consent-based heatmaps and privacy-masked interaction recordings
Better Stack
Public endpoint availability checks and incident response
Better Stack monitors public Prerender Buddy endpoints only. Its incident tooling stores monitor responses and may capture a screenshot when a failed response has a non-empty body. Authenticated customer pages and private account URLs should not be added to those monitors.
What is not confirmed here
Account-specific regions, provider retention settings, and contract acceptance.
PostHog and Microsoft Clarity may process analytics data in the United States. Other actual deployment regions and account-level retention settings require provider-dashboard confirmation and are not inferred from source code.
Customer controls
Delete sites, revoke API keys, or use the account deletion flow.
Disconnect a publishing connection to clear its stored credential and feed-key hash; revoke the destination credential separately when appropriate. Disconnecting does not delete PB drafts/history or retract remote published content.
Some provider-side records, including billing, delivered email, CMS posts, Git history, webhook copies and hosting builds, may follow the provider's own legal or operational retention rules. A PB deletion request does not establish deletion from every remote destination or backup.
Related technical boundaries