A Google Doc can be approved while its WordPress draft still contains transfer errors or unfinished publishing details. Treat the draft as a separate work item: it needs its own checks and a recorded acceptance decision before it can move to release.
This checklist helps content teams and WordPress agencies identify the source and destination, tailor QA to the transfer route, document exceptions, and hand off a clear decision. It does not cover the mechanics of every import method; it starts with the draft and the evidence needed to accept it.
Set the acceptance record for Google Docs to WordPress
Before QA begins, record four details in the assignment or handoff note:
- Approved source: The Google Doc link and approved version, revision, or approval date. If edits continue after approval, name who can authorize a replacement version.
- WordPress destination: The site and intended post or page. Add the draft URL or ID when available, and confirm the expected result is editable WordPress content rather than an embedded Google Doc.
- Owners: Name the person responsible for creating or updating the draft, the person checking it, and the person authorized to approve it for release. One person may hold multiple roles, but the approval authority should be clear.
- Acceptance condition: The required content and publishing fields have been checked, blocking discrepancies have been corrected and rechecked, any permitted non-blocking exceptions have been approved and recorded, and the approval decision is documented. The draft is not released simply because content has been transferred.
These details give the team a stable point of comparison and clarify what this checklist closes: draft acceptance and handoff, not publication or live-page verification. For a broader overview of route choices, see How to Publish From Google Docs to WordPress: Choose the Right Route and QA the Draft.
Use the transfer route to target your checks
Record the route used, then focus attention on the details that route calls for checking. The table is a QA aid, not a guarantee about what any particular tool will transfer.
| Transfer route | Focus checks in the WordPress draft |
|---|---|
| Copy and paste | Heading levels, lists, links, pasted styling, and whether images appear in the intended places |
| Export or conversion | Imported assets, resulting markup or blocks, content structure, and differences introduced by the intermediate file |
| Integration or plugin | Configured site and destination, resulting draft status, content structure, media, and any fields the workflow was expected to populate |
If the draft is missing or appears in the wrong destination, pause and resolve that first. Once the intended draft is available, record any route-specific setup or known limitation that could affect review. For more detail on moving content into a draft, see How to Import Google Docs to WordPress Without Skipping Draft QA.
Verify publishing fields and preview behavior
Use the assignment and site workflow to determine which fields apply. Check each required value in WordPress rather than assuming it was supplied by the transfer route.
- Post title: Confirm it matches the approved title or a separately recorded title decision.
- Slug: Check the intended URL text against the assignment or site convention. If it is blank or unexpected, record who will decide or correct it.
- Category and tags: Confirm the intended classification rather than accepting a value without review.
- Featured image: Check that the selected image is the intended one and is set as the featured image if the assignment requires one. This is separate from images in the article body.
- Excerpt and SEO fields: Where the workflow requires them, check the assigned values. Record any required field that still needs an owner to complete it.
- Author and status: Confirm the assigned author when applicable, and verify that the post remains a draft until release is authorized.
Open the draft preview and check heading and list display, spacing, image and caption presentation, and the behavior of important links. If a field does not apply, mark it not applicable in the QA record. If a required field is incomplete, assign its completion rather than treating a blank value as an intentional choice.
Reconcile the draft body with the approved Doc
Open the approved Google Doc and the WordPress draft together. Work from the beginning of the Doc to the end of the draft, recording each check as Pass, Fix in draft, or Return to source.
| Check | Compare | Record a failure when… |
|---|---|---|
| Title and opening | Confirm the approved title decision and that the opening text appears in the intended order. | The title is stale, text is missing, or the opening changed without approval. |
| Headings | Read the headings in order; check that each appears once and has the intended hierarchy. | A heading is missing, duplicated, converted to body text, or placed at the wrong level. |
| Paragraphs and lists | Compare section order, list items, and nesting where used. | Text is missing or repeated, or a list’s order or grouping changes its meaning. |
| Links | Check the link text and open destinations that matter to the assignment. | A link is absent, points somewhere unexpected, or its text no longer describes its destination. |
| Images and captions | Check for each required image in its intended location and for captions where used. | An image or caption is missing or misplaced, or its treatment in WordPress remains undecided. |
| Tables or other special content | Compare the information and relationships readers need to understand. | The structure is lost or a WordPress-specific alternative has not been approved. |
Correct the WordPress draft when the source is right but the destination differs. Send wording, meaning, or approval questions to the source owner or editor. If the team chooses a destination-specific substitute for a source element, record who approved the choice; do not make that editorial decision silently during cleanup.
Resolve exceptions before handing off
An exception record should state what failed, who owns the next action, how the result will be checked, and who will decide whether the draft can proceed. For example:
Exception: The approved Doc has an image after the second section, but the WordPress draft does not. Draft owner: Add the intended image and recheck its placement in the preview. Approver: Compare the corrected draft with the approved Doc and record the decision. Status: Fail until the image is present and the approver confirms the recheck.
A discrepancy that affects required content, meaning, links, required media, or a required publishing field is blocking. It must be corrected and rechecked before the draft can pass; an exception note cannot substitute for that work. If the source needs to change, return the issue to its owner and identify the newly approved version before continuing.
A non-blocking exception may be accepted without a draft fix only when it is a cosmetic difference that does not alter content, meaning, navigation, media requirements, or required fields. The named approver must authorize it. Record the difference, why it is non-blocking, who approved it, and the date in the handoff note.
Pass: The approved source and intended draft are identifiable; all required content and fields have been checked; every blocking discrepancy has been fixed and rechecked; any non-blocking exception has the named approver’s documented authorization; and the approval decision is recorded.
Fail: The source or destination is uncertain, a blocking discrepancy remains uncorrected or unchecked, a required field is unresolved, a non-blocking exception lacks authorization, or approval is missing. Keep the draft out of release and assign the next action to a named owner.
A pass allows the draft to move to the separate release process. Scheduling or publishing and checking the live page happen afterward; neither is part of draft acceptance. Run the checklist on one draft and record unresolved items before handing it to the release owner.