Quick Answer
A WordPress privacy request checklist should separate four jobs: keep the privacy policy page findable, route export requests through Tools > Export Personal Data, route deletion requests through Tools > Erase Personal Data, and keep a private request log that records owner, date, status, and evidence. For a small publisher, the best fit is a narrow operating workflow: WordPress handles the built-in request screens, the site owner keeps the decision record, and any compliance question is escalated outside the article workflow instead of guessed inside the dashboard.
Privacy Request Decision Matrix
| Operator question | Better choice | Evidence to keep |
|---|---|---|
| Where is the public notice? | Use the WordPress Privacy settings page as the site pointer | Privacy page URL, last reviewed date, owner |
| Who receives requests? | Assign one inbox owner and one backup | Admin email, backup owner, handoff note |
| What if a user asks for a copy? | Use Export Personal Data first | Requester email, confirmation status, sent date |
| What if a user asks for deletion? | Review export evidence before erasing | Export check, erase status, exception note |
| What about comments? | Check comments because they can contain names, emails, URLs, and IP context | Comment status, post URL, moderation note |
| What about technical exposure? | Review Site Health for visible errors, updates, and related configuration issues | Site Health review date, issue owner |
| What is not covered? | Do not promise legal compliance from WordPress tools alone | Escalation note, outside-system checklist |
Who Should Use This Checklist?
Use this checklist when a WordPress publisher, solo blog operator, editorial admin, newsletter creator, documentation owner, or small content team needs a repeatable way to handle privacy-related requests without turning every request into an improvised dashboard search.
This is light security and privacy operations guidance, not legal, regulatory, professional security, AdSense account, Search Console, Bing Webmaster Tools, payment, tax, tracking-consent, or data-protection-officer advice. It does not change WordPress settings, Google AdSense settings, analytics settings, email settings, cookie banners, consent tools, plugin configurations, or user accounts. The article is source-derived analysis from public WordPress documentation. No private WordPress dashboard, user table, comment record, request export, erase action, Site Health report, analytics account, ad account, email inbox, or user data was inspected for this article.
The operating problem is practical: WordPress includes privacy-related screens, but the dashboard alone does not decide who owns the request, which outside systems might also hold data, when an export was reviewed, or whether an erase request should be escalated before action. A publisher needs a small runbook so the same request is not handled differently each time.
Step 1: Confirm The Privacy Page Owner
WordPress documentation describes Privacy settings as the place where an administrator can create or select the site's Privacy Policy page. The important operator step is to record ownership, not to treat the generated page as a finished policy.
Use this ownership checklist:
- [ ] Privacy page URL is recorded.
- [ ] Page owner is named.
- [ ] Backup reviewer is named.
- [ ] Last review date is recorded.
- [ ] Navigation or footer placement is checked.
- [ ] Login and registration page visibility is checked when relevant.
- [ ] Any outside policy review is linked privately, not pasted into public source notes.
The better choice for a small WordPress site is a short owner line: "Privacy page reviewed on 2026-06-15 by the site owner; next review after plugin, form, analytics, or comment workflow changes." That line does not prove legal compliance. It only prevents the page from becoming an orphaned admin artifact.
Step 2: Route Export Requests Through One Path
WordPress documentation describes the Export Personal Data screen as a tool that can generate a data archive for data that exists inside WordPress and participating plugins. It also notes that administrators may need to go beyond WordPress for a full export request.
Use this export checklist:
- [ ] Request source is recorded, such as email, contact form, or support inbox.
- [ ] Requester email or username is entered in Tools > Export Personal Data.
- [ ] Confirmation status is checked before data is sent.
- [ ] Completed export status is recorded.
- [ ] The link availability window is noted for the requester.
- [ ] Outside systems are listed separately, such as email marketing, analytics, forms, ecommerce, helpdesk, or ad tools.
- [ ] The request log stores status and dates, not unnecessary personal details.
The best fit is to keep WordPress as the first internal system of record, then add a private "outside WordPress" checklist. Do not imply that a WordPress export covers every place a visitor's information may exist.
Step 3: Review Before Any Erase Action
WordPress documentation describes the Erase Personal Data screen and says administrators can use the export tool to confirm what data will be erased. That order matters operationally. An erase action is a change, so the owner should understand what WordPress is about to remove or anonymize before treating the request as complete.
Use this erase-readiness table:
| Check before erase | Why it matters | Owner |
|---|---|---|
| Request identity confirmed | Prevents action on the wrong person | Site owner |
| WordPress export reviewed | Shows what WordPress can see | Request owner |
| Outside systems listed | Avoids false completion claims | Operations owner |
| Comments reviewed | Comments can be public or moderated | Editorial owner |
| Plugin participation understood | Plugins may or may not contribute data | Technical owner |
| Exception or escalation noted | Some requests need outside advice | Site owner |
| Completion date logged | Creates a repeatable operations record | Request owner |
Do not use "Force Erase Personal Data" as a routine shortcut. The better choice is a request-specific record: what was confirmed, what WordPress could erase, what was outside WordPress, who approved the action, and what remains open.
Step 4: Include Comments In The Request Review
WordPress comments can include visitor-provided content and moderation states such as pending, approved, spam, and trash. A privacy request workflow should include comments because a published comment may expose more than the post editor remembers.
Use this comment review checklist:
- [ ] Search comments by requester email, name, URL, or username where appropriate.
- [ ] Check pending, approved, spam, and trash views.
- [ ] Record post URLs only when they are needed for the request record.
- [ ] Do not publish private request details in comment replies.
- [ ] Coordinate with the comment spam moderation workflow when spam status affects the review.
- [ ] Avoid changing unrelated comments during a request.
- [ ] Keep the request log private.
The better choice is to treat comment review as one line item in the request, not as a public discussion with the requester. WordPress comment moderation is visible work on a public site, while privacy request handling should stay private and minimal.
Step 5: Check Site Health For Exposure Signals
WordPress Site Health documentation describes a Status tab for critical issues and recommended improvements, plus an Info tab with technical configuration details. For a privacy request workflow, Site Health is useful because it can surface issues that affect exposure or operational trust, such as visible debugging, plugin update status, HTTPS, user counts, comment defaults, and related configuration details.
Use this Site Health checklist:
- [ ] Check whether visible errors or debug display are reported.
- [ ] Check update-related warnings before treating plugin privacy behavior as stable.
- [ ] Confirm HTTPS status.
- [ ] Note whether registration or default comments are enabled.
- [ ] Check user count and owner expectations.
- [ ] Keep Site Health exports private because they can include technical details.
- [ ] Turn repeated findings into separate site-ops tickets, not ad hoc privacy-request edits.
Site Health is not a privacy audit. It is a useful dashboard review that can prevent a publisher from missing obvious operational exposure while handling a request.
Step 6: Keep A Minimal Private Request Log
A request log should help the operator repeat the process without storing extra sensitive details. The log is for status tracking, ownership, and evidence. It is not a place to copy user data into a spreadsheet for convenience.
Use this minimal log format:
| Field | Example value | Keep it minimal |
|---|---|---|
| Request date | 2026-06-15 | Yes |
| Request type | Export or erase | Yes |
| Request owner | Site owner | Yes |
| WordPress status | Pending, confirmed, sent, completed | Yes |
| Outside-system check | Listed or escalated | Yes |
| Comments checked | Yes, no, or not applicable | Yes |
| Completion note | Closed, blocked, escalated | Yes |
Choose a private place for this record, such as an internal source-note document or admin-only tracker. Do not put the requester's personal data into public article notes, screenshots, commit messages, or distribution snippets.
Step 7: Define When To Escalate
Some privacy requests are simple WordPress operations. Others involve outside systems, unclear identity, business records, legal obligations, security incidents, minors, payments, subscriptions, advertising data, or a conflict between deletion and recordkeeping. A checklist should make escalation obvious.
Escalate when:
- [ ] The request involves non-WordPress systems.
- [ ] The requester identity is unclear.
- [ ] The request mentions legal rights, deadlines, complaints, regulators, or contracts.
- [ ] The site stores payments, accounts, memberships, or private submissions.
- [ ] A plugin owns the relevant data and its behavior is unclear.
- [ ] The request conflicts with another recordkeeping requirement.
- [ ] The owner is unsure whether erasure is appropriate.
The operator rule is simple: use WordPress tools for WordPress data, use private logs for workflow evidence, and use outside advice for compliance decisions.
What Should A WordPress Privacy Request Workflow Include?
A WordPress privacy request workflow should include a current privacy page owner, a private request inbox, Export Personal Data handling, Erase Personal Data review, comment lookup, Site Health review, outside-system checklist, minimal request log, and escalation criteria. The workflow is ready when a future operator can tell what was requested, which WordPress tool was used, what was outside WordPress, who owned the next step, and why the request was closed or escalated.
Common Questions
Does the WordPress privacy page make a site compliant?
No. WordPress provides tools and guidance, but the site owner is responsible for the actual policy content, accuracy, placement, and any requirements that apply outside WordPress.
Should an operator erase data before exporting it?
Usually no. The safer operating sequence is to review the relevant export evidence first, then decide whether erasure is appropriate for the WordPress data and whether outside systems need separate handling.
Do WordPress exports include every plugin and external service?
No. WordPress documentation notes that the export tool gathers data from WordPress and participating plugins. A publisher should still check forms, email services, analytics, ecommerce, ad systems, and other tools separately when relevant.
Should privacy requests be handled in public comments?
No. Public comments are not a good place to exchange private request details. Use a private inbox and request log, then review comments internally when they are relevant to the request.
Is Site Health a privacy audit?
No. Site Health is a dashboard review for site configuration and issues. It can help surface operational exposure, but it does not replace a privacy audit, security review, or legal assessment.
AdSense And Policy Fit
This checklist supports AdSense-safe operations because it improves privacy-page ownership, request routing, private source-note discipline, comment review, Site Health review, and escalation behavior without encouraging copied content, manufactured traffic, hidden sponsorship, affiliate claims, click inducement, fake engagement, public exposure of user data, unsupported compliance claims, or private account changes. It is an editorial operations workflow, not a monetization shortcut.
Source Notes
- https://wordpress.org/documentation/article/wordpress-privacy/ checked 2026-06-15; used for source-derived analysis of WordPress privacy tools, privacy notice scope, user data export/removal expectations, and the warning that tools are not a complete compliance process.
- https://wordpress.org/documentation/article/settings-privacy-screen/ checked 2026-06-15; used for source-derived analysis of selecting or creating the WordPress Privacy Policy page and keeping responsibility with the site administrator.
- https://wordpress.org/documentation/article/tools-export-personal-data-screen/ checked 2026-06-15; used for source-derived analysis of Export Personal Data, email validation, request states, sent data, and the limits of WordPress plus participating plugins.
- https://wordpress.org/documentation/article/tools-erase-personal-data-screen/ checked 2026-06-15; used for source-derived analysis of Erase Personal Data, confirmation flow, force erase behavior, request removal, and checking export evidence before erasure.
- https://wordpress.org/documentation/article/comments-in-wordpress/ checked 2026-06-15; used for source-derived analysis of comment moderation states and why comments belong in a privacy request review.
- https://wordpress.org/documentation/article/site-health-screen/ checked 2026-06-15; used for source-derived analysis of Site Health status, critical issues, configuration information, and exposure-related operator checks.
No private WordPress dashboard, user account, comment record, personal data export, erasure request, Site Health report, email inbox, analytics account, Google AdSense account, Search Console property, Bing Webmaster Tools account, consent banner, cookie tool, payment system, plugin database, hosting panel, or visitor record was inspected for this article. If a future operator adds account-specific request IDs, screenshots, user emails, export archives, comment IDs, Site Health exports, plugin records, or outside-system evidence, keep those artifacts private and keep public claims limited to the verified workflow.
Internal Link Notes
Link to wordpress-user-role-audit-checklist when request ownership depends on administrator access. Link to wordpress-login-protection-checklist when privacy request handling exposes weak login controls. Link to wordpress-comment-spam-moderation-checklist when comments need moderation context before review. Link to wordpress-admin-email-recovery-checklist when request emails depend on the correct admin inbox. Link to wordpress-site-health-review-checklist when Site Health findings need a broader operational review. Link to source-notes-workflow-for-blog-posts when the team needs private evidence discipline for source-derived editorial operations.
Update Note
Review this checklist every 60 days. Recheck official WordPress documentation for Privacy settings, Export Personal Data, Erase Personal Data, Comments, and Site Health before changing recommendations. Refresh earlier after a WordPress privacy-tool update, plugin change, form change, comment workflow change, analytics or ad-tool workflow change, admin email change, privacy-page update, or Yolkmeet publishing-process update.