A draft gives a business owner room to inspect a new page before customers see it. The challenge is that a page can look polished inside the editor while its actual preview contains broken layouts, unreadable text, missing images, or links that go to the wrong destination. A careful review checks the rendered draft and leaves unrelated live pages alone.
Separate draft changes from site-wide settings
Start by confirming whether you are editing an individual post, a reusable template, or a shared site component. Changing a paragraph in a draft normally affects one piece of content. Editing a global header, typography rule, or theme template can affect every page immediately. Write down the intended scope before changing anything so an audit does not become an accidental redesign.
Keep the post in draft status throughout the review. If the site uses an automated social sharing or newsletter feature, check those settings before publishing as well. Do not temporarily make the draft public just to run a public performance test; private preview access and published page behavior are different environments.
Clear ownership and editing boundaries prevent rushed content changes from affecting navigation, SEO settings, or the rest of a site.
Read the rendered page from top to bottom
Open the WordPress preview, not only the editor canvas. Verify that the first visible title is correct, headings follow a logical order, and no stray code or duplicated title appears. Most WordPress themes already render the post title as the page’s main heading; inserting another H1 inside the article can create an unnecessary duplicate.
Read the opening paragraph without relying on the headline alone. Does it answer a real customer question? Do the sections flow logically? Watch for repeated marketing phrases, empty FAQ sections, incorrect local claims, and a conclusion that adds no useful guidance. Each heading should introduce information beneath it, not simply repeat a keyword.
Test multiple screen sizes and actual interactions
Preview at 320, 375, 390, and 430 pixels wide, then check a tablet and desktop. Look for sideways scrolling, clipped headings, oversized images, overlapping blocks, and columns that become too narrow. Verify that text stays readable and that the header and footer have not been displaced by the content.
Next, interact with the preview. Open the navigation menu, use buttons, follow relevant links, and try keyboard navigation. A visual screenshot cannot prove a control is clickable. If a CTA is obscured by an invisible overlay or a form cannot receive focus, the rendered page needs a targeted correction before publication.
Separating visual issues from technical and editorial issues lets teams test the right fix before publishing.
Verify the images and their layout
Every editorial image should have a purpose. A generic photo repeated in every section adds little value, while a picture placed beside a relevant explanation can make the text easier to understand. Check the chosen media item’s real dimensions, sensible file size, and accurate alt text. Do not guess width and height values or rely on CSS to make a huge file appear small.
If the design uses image-and-text sections, confirm that images sit to the left of associated text on desktop and stack above that text on mobile. Watch for crops that remove the subject or make a caption misleading. A featured image may have a separate role from images inside the article and should be reviewed in the theme’s actual single-post template.
Check links, metadata, and search intent
Visit each internal destination rather than assuming a correctly formatted URL will work. One helpful link to a relevant site page is more useful than several links chosen solely to meet a quota; for example, a local-services discussion could link to website design in Owatonna, MN. Include related articles only where they genuinely expand the explanation.
Review the SEO title, meta description, permalink, and focus keyphrase in the SEO plugin actually installed. Avoid guessing custom-field keys. Check that the article will have the intended canonical URL and search visibility after publication, while remembering that a private draft is not normally eligible for public indexing.
Distinguish draft tests from published-page tests
Some technical checks work in a private preview: heading order, visible image layout, buttons, link destinations, alt text, and mobile overflow. Other checks require a publicly accessible page to measure the final delivery path accurately. Public caching headers, search engine indexing, sitemap inclusion, and field Core Web Vitals should not be marked as passed just because a plugin is installed or a draft preview opens.
When a site-wide issue appears, document it separately. An unexpectedly slow server response, a missing compression header, or a template-wide accessibility defect may need hosting or theme attention. Those are different tasks from polishing the draft article and should not trigger broad configuration changes without a clear repair plan.
Save, reopen, and verify persistence
Save the draft and reopen it. Recheck the title, slug, excerpt, category, featured image, article content, and available SEO values. The final readback is important because an editor can appear to accept a value that is not actually stored. Record any check you could not perform rather than inventing a passing result.
For a related perspective on how websites change after launch, read how often a small business should update its website. A well-reviewed draft provides a clearer starting point for future updates, whether the site has one service page or dozens of local landing pages.
The decision before publishing
Publish only after the visible content, important links, mobile presentation, and saved settings are verified. Keep an unresolved-issues list for work that requires a public environment or a site-wide change. The goal of draft review is not to manufacture an all-green report; it is to make the next decision with evidence and without disturbing pages that are already working.