A WordPress homepage can look fine one minute and strangely incomplete the next. A logo may appear twice. Navigation can disappear. A row of articles can stop updating. On mobile, cards may stretch past the edge of the screen.

The tempting response is to rebuild the whole page. That is usually more work than the problem requires.

We recently repaired the SideQuestStack homepage after a header edit left the template structure malformed. The recovery worked because we treated the page like a system with separate layers, not one giant design. Here is the process we used and the lessons worth keeping.

First, identify which layer is actually broken

WordPress block themes separate content into pages, templates, and template parts. A visible problem on the homepage does not automatically mean the homepage content is the cause.

Start by sorting the issue into one of four layers:

  • Page content: headings, paragraphs, buttons, and sections unique to the homepage
  • Template: the structure that places the header, page content, and footer together
  • Template part: a reusable element such as the site header or footer
  • Styles: colors, typography, spacing, and layout rules that can affect many pages

In our case, duplicated branding and missing navigation pointed to the shared header, while stale article cards pointed to the homepage content. Those were two different problems. Treating them separately kept a header repair from turning into a full homepage rebuild.

Preserve a known-good version before editing

Before changing blocks, find the most recent version that still worked. WordPress stores revisions when content is manually saved or published, and WordPress.com lets editors compare and restore earlier versions.

We used a known-good header revision as the clean base. That gave us a reliable structure to restore before adding the missing Field Notes link.

This is safer than trying to untangle malformed block markup one fragment at a time. If the structure is already damaged, every new edit adds another variable.

Use this short recovery checklist:

  1. Open the affected page, template, or template part.
  2. Review its revision history.
  3. Find the last version with the correct layout and navigation.
  4. Restore or copy only the working blocks you need.
  5. Save once, then inspect the public page before making another change.

WordPress.com explains how revisions and partial restoration work in its revision guide.

Repair the smallest complete unit

A header is not just a row of links. It may include a site logo block, a navigation block, a button, groups that control spacing, and opening and closing block comments.

When block markup is edited as code, those pieces must remain balanced. A missing closing comment can make WordPress reinterpret everything that follows it. The visible symptom may show up far from the actual mistake.

Our rule was simple: replace the smallest complete unit that could be verified. For the header, that meant restoring the whole known-good header structure and then inserting one complete navigation link. It did not mean replacing the entire site template.

That distinction matters. Small, complete repairs are easier to test and easier to reverse.

Replace manually maintained article cards with a Query Loop

The homepage also had a content problem. Its Field Notes cards were static. Publishing a new article did not update the homepage, so the newest posts were missing.

We replaced those cards with a Query Loop. WordPress describes the Query Loop as a way to display posts based on chosen parameters. Its Post Template controls the design repeated for every result.

For SideQuestStack, the loop now shows the six newest posts in newest-first order. Each item uses the same card structure, so a newly published article can appear without someone rebuilding the section.

This is a good fit when a page needs:

  • the latest posts
  • a category-specific library
  • a consistent grid of titles, dates, and excerpts
  • content that updates automatically

The official Query Loop documentation explains its filters, ordering, Post Template, and layout controls.

Verify the public result, not just the editor

The editor is useful, but the public page is the final product. After the repair, we checked the live homepage for specific outcomes:

  • one logo, not two
  • one header call-to-action
  • the full navigation menu
  • the four published articles in the expected order
  • one H1
  • no invalid blocks
  • no horizontal overflow

We also tested an actual 390-pixel viewport. The page width matched the viewport, the article cards stacked into a single column, and the mobile menu controls remained visible.

A visual glance at a narrow desktop window is not the same as a mobile check. Measure the page at a real mobile width and confirm that the document is not wider than the viewport.

The practical lesson

A broken homepage does not always need a redesign. It needs a careful diagnosis, a recoverable starting point, and a narrow repair.

The most reusable workflow is:

  1. Identify the broken layer.
  2. Restore a known-good complete unit.
  3. Make one controlled change.
  4. Save and inspect the public page.
  5. Test both desktop and mobile behavior.
  6. Record what was checked.

That process is slower than clicking around for the first few minutes. It is much faster than rebuilding a site after a repair creates three new problems.

For another practical decision framework, read What Should You Automate? A Practical Five-Part Test.