A website can look finished while the person who must maintain it cannot safely change a headline. Design approval and editor acceptance answer different questions. Both need evidence before the build is handed over.
TLDR: Ask a real editor to complete routine tasks using the intended permissions and documentation. Test content flexibility, previews, accessibility and escalation paths on approved test content. Record what the editor can do independently and what still requires a developer.
We recommend choosing representative tasks: editing a heading, replacing an image, adding a section, changing a button destination and checking a form. Avoid demonstrating only the cleanest example page.
Use a draft or approved test page with synthetic content. Keep production changes and form submissions outside the test unless they are explicitly authorized. A handover exercise should not accidentally send emails or modify live customer records.
If you are still comparing platforms, the WordPress and HubSpot CMS comparison addresses that earlier decision. Acceptance begins with the build and editing model you actually selected.
As checked on September 7, 2026, HubSpot separates content permissions, including editing and publishing access. Review the specific user's permissions rather than testing only as a Super Admin. HubSpot user permissions guide
We recommend confirming who can edit, approve and publish. If the editor cannot complete a task, determine whether the cause is a permissions decision, missing documentation or a module limitation. Those require different fixes.
Document the escalation path without solving every limitation by granting broader access.
The following script is a proposed acceptance exercise, not a completed test of a Selworthy or client website.
For each task, record expected behavior, actual behavior, evidence and disposition. Do not mark “pass” because the developer completed the task while the editor watched.
HubSpot documents previews for different device types and for supported personalization or smart-content conditions. Its preview links are intended for internal account review, with access limitations on some system-domain previews. HubSpot page preview documentation
We recommend testing the longest realistic heading, a short section, a missing optional image and a longer button label. Check that the page remains readable and that an editor can understand which fields are required.
Use keyboard navigation for links, controls and any interactive elements. Verify meaningful link text and image descriptions. These checks identify issues to fix; they do not by themselves certify accessibility compliance.
The landing-page guide provides useful context for the page's conversion task. The acceptance test should confirm that routine edits preserve that task.
HubSpot documents version history and restoration for supported content. It also recommends cloning content if you need a separate copy before restoring an earlier version. Confirm permissions and the relevant content type before relying on that process. HubSpot content restoration
Do not call this a universal site rollback. We recommend documenting the separate recovery process for page content, shared modules, theme code, forms and integration settings where applicable.
User acceptance testing should show whether the intended editor can maintain the delivered site. It is distinct from a developer confirming that the code runs or a stakeholder approving the visual design.
Choose tasks from the team's actual publishing routine. Include a blog page, a landing page and a more complex page when those are in scope. Keep unrelated Sales Hub setup, data migration or service automation outside this focused CMS handover.
A task such as “replace the hero image” should include selecting the approved asset, entering accurate alt text, inspecting the crop and saving the intended version.
A task such as “update the CTA” should include changing the label and URL, then checking the destination. A visible button is not proof that its link is correct.
Record whether the editor completed the task independently, needed documentation or required implementation help. Those results guide the handover materials.
The editing model should make routine content changes understandable. Ask the editor to identify which fields are required, which are optional and which affect shared content.
Do not assume a module is easy to maintain because the developer knows its field names. Use the editor's observed task result and feedback.
If a requested layout change requires code, document the boundary. A clear escalation path can be acceptable; an undocumented limitation discovered after launch is harder to manage.
An editor needs to know whether a change affects one page, several pages or a shared site element. Include that distinction in the module guidance.
Use approved test content to demonstrate the scope. Do not change a production shared element merely to prove the concept.
The acceptance record should identify the expected affected pages and the evidence checked. A change saved on one page does not establish its effect elsewhere.
Routine editing should preserve a useful page title, one clear main heading, readable text, meaningful links and accurate image descriptions.
Use a real small-screen preview or viewport to inspect the result. Check long headings, narrow tables and button labels rather than relying only on a desktop screenshot.
Ask the editor to find the metadata controls and explain what should change when the page's purpose changes. Keep the metadata consistent with the visible content.
The task should not require the editor to invent a new SEO strategy during acceptance. Provide a realistic approved example and assess whether they can apply it correctly.
A form preview can show labels and layout. A real submission may create or update a contact, trigger routing or send communications.
Separate those tests. Use an approved synthetic submission only when its effects and cleanup are understood. Do not treat a content handover as blanket permission to enroll contacts or trigger follow-up.
Ask the editor to identify the saved draft, the public version and the next approval or scheduling step. Confirm the actual permissions selected for that person.
A change appearing in preview is not a published change. The handover should preserve that distinction so the team does not confuse saving with release.
Group findings into defects, documentation gaps, permission decisions and new scope requests. Give each an owner and a clear completion condition.
A defect means the delivered behavior differs from the agreed requirement. A request for a new module may be useful but should not be disguised as an existing feature that is broken.
Page content, theme code, shared modules and integrations can have different recovery methods. Identify the appropriate method and owner for each part of the delivered site.
Do not label page version history a complete site backup. Test only the approved recovery scope and record what remains unverified.
Keep concise task instructions with the module or handover pack. Show the steps the editor will repeat and the checks that indicate a successful result.
A recorded demonstration can help, but it should accompany actual editor practice. Watching someone else complete the task is not equivalent to demonstrating independent use.
The agreed editor tasks have observed results, material defects have a disposition, documentation covers the routine work and the publishing and support responsibilities are clear.
Completion does not mean the editor can perform every future design or development task. It means the delivered operating model matches the agreed scope and can be maintained by the intended team.
The final handover should include the editor's task results, known limitations, module guidance, publishing responsibilities and support route. Mark unresolved defects with an owner and acceptance condition.
Screenshots should come from approved test content and show the actual state being accepted. This article supplies a test script, not fabricated screenshots or evidence that any build has passed it.
For help designing an editing experience your team can maintain, explore website design services or request a scoped review.