Exterior Renovations: Broken Image Fix — 'How to Tell When Your Siding Needs Replacing' (2026-01-29)

Overview

During a weekly Ahrefs audit of the Exterior Renovations site, a broken image was detected on the blog post "How to Tell When Your Siding Needs Replacing." The image — a woodpecker clinging to damaged wood siding, illustrating the Pest Damage section — had a valid alt text entry but no actual image file rendering. The fix involved replacing the image in WordPress and flushing the WP Engine cache to ensure the corrected version propagated across all CDN locations.

This fix was performed live during the ^[1] as a demonstration of the new weekly Ahrefs maintenance workflow.

Issue Details

Field	Detail
Detected by	Ahrefs site audit
Page	Blog post: "How to Tell When Your Siding Needs Replacing"
Section	Pest Damage
Image alt text	"A woodpecker clings to wood and peeling wood and siding"
Symptom	Image placeholder visible on live page; no image rendered
Root cause	Image file missing or URL broken in WordPress media library

Fix Applied

Step 1 — Locate the broken image

Ahrefs flagged a broken image error but does not pinpoint the exact location on the page. The page was loaded and scrolled manually to find the missing image block under the Pest Damage section.

Step 2 — Replace the image in WordPress

Navigated to Posts in the WordPress admin for Exterior Renovations.
Opened the "How to Tell When Your Siding Needs Replacing" blog post in the editor.
Located the broken image block under the Pest Damage section.
Deleted the broken image block.
Inserted a replacement woodpecker image sourced from the existing WordPress media library.
Resized the image to an appropriate display size.
Published/updated the post.

Step 3 — Flush the WP Engine cache

After publishing, the WP Engine cache was cleared to ensure the fix propagated to all CDN edge locations:

WP Engine Dashboard → Caching → Clear All

Why this matters: WP Engine distributes cached copies of the site to CDN nodes across multiple geographic locations. Without flushing, visitors may continue to see the old broken version until the cache naturally expires. Flushing forces an immediate refresh across all nodes.

Cache rebuild time is typically a few minutes. The site may load slightly slower during this window while CDN nodes repopulate.

Step 4 — Verify the fix

Loaded the page in an incognito window (bypasses any local browser cache) to confirm the image rendered correctly on the public-facing site.
Initiated a new Ahrefs crawl so the broken image error would be cleared from the audit report.

Key Learnings

When logged into WP Engine and browsing the site, WordPress loads the backend and frontend simultaneously — causing the site to appear slow. This is expected behavior and does not reflect public-facing performance. Always test site speed in an incognito window to get an accurate read.

Ahrefs flags errors but doesn't locate them

Ahrefs will report that a broken image exists on a page but will not identify exactly where on the page it appears. Manual inspection of the page is required to find and fix it.

Cache flush is a required step after any content fix

Any time content is updated in WordPress on a WP Engine-hosted site, the cache should be flushed to ensure the fix is live everywhere. Skipping this step can result in the broken version persisting for an indeterminate period across CDN nodes.

This fix was performed as part of the new weekly Ahrefs maintenance routine established during this call. See ^[2] for the full process.

Routine: Block 30 minutes weekly to review client sites in Ahrefs for errors. For each error:
- Create a ClickUp task for fixes that can be handled directly.
- Escalate to Melissa for larger structural issues.
- Initiate a new Ahrefs crawl after fixes are applied.

^[3]
^[4]
^[5]
^[2]