Treat an image as a separate resource

An image in a generated article needs more than a temporary URL. Store where the file came from, whether you can publish it, its intended caption, and its relationship to the article. WordPress has a separate media resource, while posts can reference featured media. That separation suggests a reliable workflow: prepare the asset, upload it, record the returned identifier, and then connect it to the post. These steps are a recommended implementation pattern. They avoid assuming that embedding a file address also creates a managed library asset.

Prepare files for the real page

Choose an appropriate size for the article layout and inspect the image at its displayed dimensions. A product screenshot should retain legible labels, while a decorative image should not outweigh the rest of the page unnecessarily. Provide useful alternative text based on what the image communicates; do not fill it with repeated search phrases. A hypothetical inventory app might need a cropped stock dashboard with a caption explaining the example values. Remove customer information and private account details before uploading. Keep an original asset if later recropping will be necessary.

Upload before finalizing references

Complete asset uploads before constructing the final body references. Persist both the remote media identity and the resulting address, since later edits may need one or the other. If an upload times out, investigate whether the asset was created before retrying. A local fingerprint can help your own system identify a previously processed source file. Do not assume the destination deduplicates identical uploads. For the inventory example, retrying a single failed article should not leave five copies of its dashboard screenshot scattered through the media library.

Distinguish featured and inline uses

The hero image and an instructional screenshot serve different purposes, even when a theme displays them similarly. Map featured media deliberately, then insert inline illustrations where they explain a step. Check that the theme does not display the hero twice because it appears both in the featured slot and at the beginning of the body. Verify captions, links, and alternative text in the final HTML. A content review should also confirm that an image supports the nearby statement and does not imply a product capability that the software does not offer.

Clean up with references in mind

Failed drafts can leave unused assets, but deleting all recently uploaded files is unsafe. Track which articles reference each asset and separate genuinely unreferenced files from shared images. Use a reviewable retention policy for failed-job assets rather than immediate deletion during an uncertain network response. After publication, check that images load without temporary credentials or expiring source links. If the publishing connection is removed, the customer should still understand where their public images live. A successful media pipeline produces stable, attributable assets that remain usable after the original generation job is forgotten.

Add a failed-image scenario to testing: the article body should remain recoverable when the hero upload fails. Decide whether publication pauses or proceeds without that optional image, and make the decision visible to the editor.

PUT IT TO WORK

Upload and track images independently, then verify their placement and stability on the published page.

Sources & further reading

Official documentation informs this guide. Examples are illustrative, and product interfaces or limits can change.

THE WORKSPACE WE'RE BUILDING

From search signals to a useful first draft.

SERP.so is in development. Join the waitlist for a workspace that connects research, content review, and publishing.

Join early access ↗