Auditing a Landing Page Redesign: 13 SEO Bugs You’ll Hit

Build Diary · 03 ·

Auditing a landing page redesign before launch — 13 SEO bugs, every minute timestamped.

A 2-hour chat-driven SEO audit on a pre-launch SaaS landing page. Three bugs, three breakthroughs, one dead end. Including the moment we found an entire body-text block written about a different product — and the moment a single-tool keyword constraint surfaced a zero-competition keyword the big tools missed.

Build time
2h 06m
Bugs fixed
3
Breakthroughs
3
Dead ends
1
  1. Start

    The plan: audit a redesigned landing page before it goes live.

    A real-estate SaaS had redesigned the landing page for their main product and asked for an SEO review before pushing it to production. The page was beautiful — better hero, cleaner stats, animated step-by-step “how it works” cards. The brief was short: extract the heading structure, do keyword research, and tell me what to change. Three data sources lined up: Google Keyword Planner for volumes, Google Search Console for the current page’s organic traction, and competitor SERP data to see what was beating it. Two hours later we had a different page.

  2. Eureka ✦

    Two whole sections were about a different product.

    The shift: this isn’t a copy-tweak job — the CMS imported text from a sibling page and Google’s strongest body-text signal points at the wrong keyword.

    Extracted the headings into a flat list. The stats H2 said “What You Get with AI Image Enhancement” — on a page about a different feature entirely. Scrolled to the bottom. The whole SEO content block — one H2, five H3s, ~200 words of body copy — was written about item removal. None of it was about the actual product the page was selling. This is what topic drift looks like in a CMS redesign: when the template is reused across sibling pages, body copy travels with it. The largest text block on the page was teaching Google about a keyword the page doesn’t sell.

    Screenshot of the review document showing the bottom SEO content block — an H2 and five H3s all written about a different product than the page's actual topic.
    Section 11 of the review document. The entire SEO content block — H2 plus five H3s — was written about a sibling product. Every paragraph beneath these headings reinforced the wrong topical signal.
  3. Bug 01⏱ 5 min · 🧠 reusable lesson

    The visually-dominant H1 carried no keyword.

    Symptom
    The H1 was split into two <span> elements — a small eyebrow with the brand keyword, and a large main line that said “Stage the Space. Sell the Vision.” Beautiful. Search-irrelevant.
    Root cause
    The copywriter optimized the visually-dominant line for emotion. The eyebrow absorbed the keyword by accident, but eyebrow text is the secondary signal — Google reads the larger H1 first.
    Fix
    Replace the main span with “Virtual Staging Software — Stage Any Room in Seconds”. Captures the head term (5,400/mo) and the LOW-competition “software” qualifier (880/mo, competition index 33). The poetic eyebrow stays; we just stopped wasting the dominant line.
  4. Bug 02⏱ 18 min · 🧠 reusable lesson

    The audit was content-only — it missed everything else.

    Symptom
    First draft of the review only critiqued heading text. The client asked: “what about semantic tags, images, performance?” The page had a section subtitle marked up as <h2>, the mobile view duplicated every H2, and four testimonials all reused the same two before/after image URLs. None of that came up.
    Root cause
    Anchored on the literal request (“heading structure”) and skipped the scaffolding. A real audit covers content and markup and media and performance — they’re all SEO signals.
    Fix
    Rebuilt the document as 13 sections covering: head meta, hero, marquee, how-it-works, stats, features, testimonials, audiences, FAQ, CTA, SEO content block, sitewide observations, and competitor gaps. Inside each: content + semantic + media + performance notes. Hero video using preload="metadata" with autoplay (LCP risk). Testimonial avatars rendered from transparent 1×1 GIFs. Editor wrapper attributes (data-editable-*, data-astro-cid-*) inflating the DOM. None of these would have surfaced from a heading-only audit.
  5. Eureka ✦

    The CMS panel was set up but never populated.

    The shift: the redesign team built the plumbing for Open Graph and JSON-LD but never filled the values — two distinct failure modes hiding on the same page.

    Mid-audit, the client pasted a screenshot of the CMS Page SEO panel. Empty meta tags. Empty schemas. curl on the production HTML confirmed it: <title> was literally the slug (virtual-staging-service), meta description was an empty string, no og:title, no og:description, no og:image, no schemas. The redesign team had built the editor controls but never used them. This is its own bug — separate from the topic drift — and on the same page.

    Screenshot of the CMS Page SEO panel showing empty Meta tags section and empty JSON-LD schemas section.
    The CMS exposed structured fields for OG tags and JSON-LD schemas. All empty. The plumbing was ready; the audit’s job was to fill it.
  6. Dead end⏱ 10 min

    Trying to explain why /og/virtual-staging is not a URL.

    The client asked: “is /og/virtual-staging the right URL for the page?” The slug looked like an Open Graph artifact, and OG was the topic of the conversation, so the assumption was logical. The instinct was to dive into the protocol spec — what property="og:url" means, why path namespaces are unrelated, how scrapers resolve the canonical URL. Ten minutes of explanation later the client was more confused, not less.

    What I learned: when explaining technical concepts to non-specialists, lead with where the thing lives, not what it does. “Open Graph tags live in <head>, never in the URL” is one sentence that answers the question before they ask it. The protocol spec only matters once they trust the placement.

  7. Bug 03⏱ 7 min · 🧠 reusable lesson

    Social URLs drifted to 404s during the redesign.

    Symptom
    Building Organization schema required sameAs social URLs. The redesigned footer pointed at linkedin.com/{brand}/, youtube.com/{brand}/, tiktok.com/{brand}/ — all of which return 404. Real platform URLs need specific path structures (/showcase/..., /channel/UC-..., /@username).
    Root cause
    Copy/paste between branches during the redesign collapsed every social link into the same flat platform.com/brand/ shape. The CSS was perfect; the URLs themselves had been silently broken.
    Fix
    Curl’d the live production page (still the old design) and extracted the verified URLs from its footer. Used those in the schema. Flagged the broken redesign footer URLs separately — they need to be replaced in the redesign before launch, not just in schema.
  8. Eureka ✦

    The single-tool keyword constraint paid off.

    The shift: a constraint that felt limiting at the start of the audit produced the highest-ROI keyword find of the day.

    For the SEO content rewrite, the brief was strict: use only Google Keyword Planner. No Ahrefs, no SEMrush. The first instinct was to argue — competitor data adds context. The constraint stuck. Pulled GKP for per-room virtual-staging queries and the table came back with virtual staging bedroom at 140 searches/month, competition index 0. Then what is staging in real estate at 90/mo, competition index 4. Both terms were absent from the Ahrefs SERP overview run earlier — buried under noisier head-term competitors. The GKP-only constraint surfaced the lowest-competition long-tail terms in the entire audit. The constraint was the win.

  9. Shipped

    Audit handed off. Every recommendation grounded in real data.

    Final deliverables: a 13-section heading-by-heading review document, a rewritten SEO content block (H2 + five H3s + closing paragraph) targeting GKP-verified keywords, 14 OG and Twitter meta tag entries, three JSON-LD schemas (SoftwareApplication, BreadcrumbList, Organization), and a new FAQ entry for the comparison-intent query. Every schema value was either pulled from the page itself or from production HTML via curl — nothing fabricated. The client implemented the OG tags before the call ended.

    Screenshot of the CMS Page SEO panel after the audit, showing seven meta tag entries filled in: og:type, og:site_name, og:title, og:description, og:url, robots, and author.
    The same CMS panel after applying the audit’s recommendations. Open Graph tags populated, robots directive set, author field filled. The brand name and URL in the screenshot are blurred — this diary is anonymized at the client’s request.

The honest accounting

Where the 2 hours actually went.

Most SEO audit estimates lie because they assume the page is roughly correct and only needs tweaks. This one wasn’t — and the rewrite work after finding topic drift was the biggest single category.

Setup
25m
Debug bugs
35m
Dead ends
10m
Eureka moments
20m (worth it)
Polish & ship
36m

Takeaway: most time went into rewriting copy after discovering topic drift in the CMS-imported content — a heading-only audit would have missed this entirely. The fastest win was the single-tool keyword constraint at minute 122; the deepest cost was Bug 02, accepting the brief literally instead of expanding scope at minute 22.

Questions you might have

The five real questions about this.

What is topic drift in a CMS redesign?

When a CMS template is reused across sibling pages, the body copy of one page can end up on a page about a different product. Google reads the largest body-text block as the strongest topical signal — so a page whose biggest text block is about the wrong product ranks for neither well. The fix is to audit every text block against the page’s actual H1 intent.

How do you find broken topical signals on a landing page?

Extract every heading and large body block into a flat list, then check each one against the H1’s primary keyword. If a block doesn’t share at least one keyword from the H1 cluster, flag it. We caught two entire sections that way — a stats H2 about a different product, and a 200-word SEO block written for a sibling page.

Should Open Graph tags use property or name attributes?

Open Graph tags use property: og:title, og:description, og:image, og:url. Twitter Card tags use name: twitter:card, twitter:title, twitter:image. Standard meta tags (description, robots, author) also use name. Most CMS Page SEO panels have a dropdown to pick between the two — picking the wrong one causes Facebook and LinkedIn to silently ignore the tag.

Why use only Google Keyword Planner for a landing page audit?

Google Keyword Planner reports the same volumes Google’s own ranking system sees, with no third-party model layered on top. Ahrefs and SEMrush estimate from clickstream data — useful for competitor research but noisy for absolute volume. For content writing decisions on a single page, GKP’s competition index lets you spot low-competition long-tail terms that the bigger tools smooth over.

How long should a pre-launch landing page audit take?

For a single landing page with full keyword research and competitor SERP review: 90 minutes to 3 hours. This one was 2 hours and 6 minutes. The biggest variable is whether the page has topic drift — rewriting body copy after finding wrong-topic blocks accounts for most of the time. Heading-only audits run under an hour but miss the most important issues.

Build Diaries · A series on shipping AI-built work to production — every minute timestamped, every dead end shown, every breakthrough named.

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top