WordPress for a coworking marketing site

This guide scopes WordPress to a public coworking marketing site and one minimal tour form. Core documentation does not verify any host, theme, plugin, form, email route, accessibility outcome, or restore.

1. Coworking outcome

Publish accurate location, amenities, accessibility, and contact information and reliably hand a minimal tour request to named staff. WordPress augments publishing/capture; humans own claims, lead response, accessibility, privacy, and operations.

2. Pilot scope

Build private non-indexed staging with minimum pages, one reviewed theme, one form solution, only required supporting plugins, synthetic leads, and test delivery sinks. Exclude production DNS/data, payment, membership, billing, access control, and identity documents.

3. Fit

Good fit: a marketing-owned site with technical maintenance, managed or competent hosting, minimal reviewed dependencies, individual users, spam controls, monitored form delivery, tested backups, and publishing approvals.

4. Non-fit and alternatives

Poor fit: an unmaintained plugin collection, membership/billing database, card capture, or ownerless launch. Compare a maintained static-site builder or managed website/form service when dynamic plugins or self-host duty are unnecessary; preserve the current site/contact channel until acceptance.

5. Coworking use cases

• Publish location, amenities, access, community, event, and contact content.
• Capture one minimal tour request with a direct fallback route.
• Maintain reviewed redirects and search metadata during a site migration.

Membership, billing, payment, and door access are excluded.

6. Tasks reduced or augmented

WordPress can streamline approved page/post publishing and, through separately reviewed plugins, form capture and caching. It cannot verify factual claims, guarantee delivery/SEO/accessibility/security, qualify leads, choose dependencies, or replace patching and incident response.

7. Human decisions and approvals

Marketing approves content/claims; privacy approves fields, retention, notice, and third parties; accessibility approves launch evidence; security approves dependencies/exposure; technical/change owners approve deploy/rollback; the lead owner approves delivery/fallback. Changes renew relevant approvals.

8. Owners and RACI

Name accountable marketing/site and technical owners, responsible editors/lead responders, domain/DNS/hosting/recovery owners, privacy/security/accessibility reviewers, and a release approver. Contractors use expiring individual access; no author silently approves their own legal or privileged change.

9. Prerequisites

Inventory domain/DNS, current site/content/media rights, redirects, analytics, forms, users, dependencies, traffic baseline, search ownership, fallback contact, retention, and legal pages. Define minimum pages, form fields/destinations, publishing workflow, update owner, and rollback window.

10. Skills and effort boundary

The pilot needs WordPress/runtime, DNS/TLS/hosting, database/files, theme/plugin, form/email, security, backup/restore, accessibility, content, privacy, and lead-operations skills. The catalog’s 1-3 days is unverified and excludes content migration, remediation, expert review, and production maintenance.

11. Deployment choice

Compare managed WordPress and self-hosting for updates, staging, backup/restore access, logs, email, support, data location, plugin limits, export, and exit. Follow official documentation plus selected host/runtime sources; this guide certifies no host.

12. Architecture and dependencies

Map registrar/DNS/CDN, TLS/proxy, web runtime, database, uploads, theme/plugins, outbound email, spam/form service, lead destination, backups, monitoring, and admin access. Identify every submission copy and behavior when email/CRM is unavailable.

13. License and edition boundary

WordPress core is GPL-2.0-or-later; verify the selected release at the core repository. Themes, plugins, fonts, media, hosts, and managed-service terms/licenses are separate and require an inventory.

14. Total cost boundary

Record domain, hosting, TLS/staging, design/content, accessibility/privacy/security review, forms/email/spam, backups/monitoring, core/theme/plugin updates and premiums, incidents, maintenance/support, migration, and exit. Free core does not make operation free; no provider price is asserted.

15. Data map

Data	Purpose	Minimum handling	Exit record
Pages/posts/media	Public marketing	Approved claims/rights	Content export plus source media
Minimal tour fields	Lead response	Name/contact/minimum request	Reconciled protected lead list
Users/roles	Publishing/admin	Individual least privilege	Access/offboarding register
DB/uploads/config/dependencies	Site operation	Protected backups/inventory	Full backup plus manifest

Payment, identity-document, door, and member billing data are prohibited.

16. Privacy and retention

Minimize fields, identify every storage/delivery destination, publish appropriate notice, set retention/deletion, restrict exports, and provide a request route. Keep sensitive data out of URLs/notifications and separately review analytics, spam, fonts, maps, video, and form providers.

17. Security baseline

Use TLS, individual least-privilege users, strong supported authentication, supported updates, private staging, restricted admin/database, managed secrets, minimal dependencies, protected backups, monitoring, and tested offboarding. Remove unused themes/plugins and restrict installation/update authority.

18. Compliance and expert review

The operator owns advertising truth, accessibility, privacy/cookies, copyright, email, consumer, and local business obligations; scans/settings are not compliance proof. Require security expertise for custom/complex code or compromise, accessibility review for launch/redesign, privacy/legal review for forms/analytics/claims, and database experts for major recovery/migration.

19. Integration boundary

No form, SMTP, CRM, booking, analytics, map, cache, payment, SEO, or other plugin is catalog-verified. Record official source/version, license/terms, maintenance, data/subprocessors, credentials, failure mode, update owner, disable method, and replacement for every dependency.

20. Configuration baseline

Record domain/DNS/TLS, host/runtime/database, environment/indexing, exact core/theme/plugin versions, users/roles, URLs/redirects, form fields/storage/delivery/spam/retention/fallback, mail, privacy settings, scheduled jobs, backups, monitoring, update/rollback, and secret references. Never store secrets here.

21. Smallest useful experiment

Following official docs, build the private minimum site and one tour form. Submit synthetic leads, exercise spam/delivery failure, test content/accessibility/roles, export content, and restore a clean copy before DNS change.

22. Implementation sequence

1. Freeze current DNS, redirects, content, contacts, users, and analytics baseline.
2. Approve hosting, architecture, pages, theme/plugins, form, and data map.
3. Create private staging with TLS, named users, backups, and no indexing.
4. Build accessible content and minimum form with fallback.
5. Test roles, forms/email/spam, mobile, accessibility, performance, updates, security, export, restore, and rollback.
6. Obtain marketing/privacy/accessibility/security/technical approvals.
7. Cut over reversibly while monitoring redirects, forms, and lead reconciliation.

23. Migration and rollout

Map content/media/redirects/forms/users before migration, freeze unrelated edits, rehearse import and redirects, and keep old site/contact available. During bounded cutover supervise both lead routes, reconcile submissions/content, and do not retire prior service until DNS/TLS/redirect/form/accessibility/recovery acceptance.

24. Required test plan

Test desktop/mobile, keyboard/focus/labels/errors/contrast/zoom and representative assistive technology, links/redirects, roles/unauthorized access, form success/validation/spam/provider failure/duplicates, email/fallback, JavaScript-off behavior where required, performance, backup restore, export, update, security, and rollback.

25. Acceptance criteria

Approved pages/claims and redirects render; no critical accessibility blocker remains; only authorized users administer; every synthetic form submission/failure is reconciled; fallback works; data destinations match approval; clean restore, update, rollback, TLS/DNS, and monitoring pass; all named owners sign.

26. Success metrics

Track synthetic form delivery/acknowledgement, lost/duplicate reconciliation, broken links, critical accessibility findings, performance, availability, backup age, patch time, incidents, and operator effort against baseline. Lead/revenue impact requires separate booking/CRM evidence; no staffing savings are assumed.

27. Monitoring and alerting

Monitor public reachability, TLS, DNS as appropriate, critical page content, safe synthetic form/delivery, backups, storage, and supported update/security notices. Assign human owners, test routes, and keep real lead data out of monitoring payloads.

28. Operating cadence

Review users/contractors, content/links, form queue/delivery/spam, privacy requests, dependencies/advisories, updates, backups/restores, storage/performance, accessibility regressions, DNS/TLS, and licenses on defined cadences. Remove abandoned dependencies promptly.

29. Failure modes and response

Plan for DNS/TLS/host/database failure, compromise/malware, bad update/plugin conflict, inaccessible content, form/email/spam/CRM loss, traffic overload, backup failure, and admin lockout. Enable fallback contact for lead failure; for compromise isolate, preserve minimum evidence, rotate credentials, patch root cause, restore known-good state, and follow notification advice.

30. Backup procedure

Create a consistent encrypted off-host backup of database, uploads, approved themes/plugins, and required configuration with checksums, versions, and dependency inventory. Protect it as form submissions/credentials may be present. A content export or host snapshot alone is not complete off-host recovery.

31. Restore drill

Restore to clean isolated staging with outbound email/form automation redirected to test sinks; replace environment URLs/secrets safely. Verify pages, media, redirects, users/roles, theme/plugins, forms, scheduled tasks, privacy controls, admin recovery, and synthetic lead/accessibility regression. Record observed time.

32. Upgrade, rollback, and exit

Review every component’s release/compatibility notes, back up, update attributable groups in staging, test, and approve release. Stop for security, error, form, accessibility, redirect, or performance failure and restore tested prior files/database/deployment/DNS while reconciling leads/content. Exit requires domain control, redirects, content/media/full backup, manifest, users, and reconciled leads; revoke and delete old service under policy.

33. Sources, evidence, and unknowns

Reviewed 2026-07-17: WordPress.org, core repository, and official documentation. Evidence is core documentation review only.

Untested: host terms/cost/support, runtime, theme/plugin licenses/maintenance/behavior, forms/email/export, traffic, backups/restores, integrations, certifications, accessibility conformance, security, upgrade/rollback, and recovery times. Every selected component remains an open gate.