Pre-Launch QA Checklist: SEO & Content Bugs Devs Miss

Your feature works. The API calls fire correctly, the tests pass, and the staging environment looks clean. Then a content manager pastes a 900-word bio into a card designed for a two-line excerpt, and the layout collapses on a mid-range Android phone while Google's crawler quietly ignores half the page. None of that shows up when you test with three words of Lorem Ipsum on a 27-inch monitor.

This checklist exists because "it works on my machine" was never actually a QA standard. It was a guess. Run through these five categories before every deploy, and bookmark this page so you stop relearning the same lessons release after release.

Stress-Test Every Component With Real, Messy Content

Developers build with clean data. Content managers work with reality: long headlines, mismatched heading levels, and copy pasted straight from Google Docs or Word, which drags along invisible inline styles and stray span tags.

Before launch, run these tests against every content-driven component:

• Paste a headline that's three times longer than your design mockup and check for truncation, overflow, or broken flexbox alignment.
• Paste rich text copied from an external document and inspect the rendered HTML for leftover inline font-family or color styles that fight your design system.
• Drop in a string with no spaces (a long URL or a hashtag with no breaks) and confirm the container doesn't blow out horizontally.
• Swap in a right-to-left language or an unusually long word (German compound nouns are a good stress test) to see how your grid reacts.

CSS already gives you the tools to survive most of this. overflow-wrap: break-word and text-overflow: ellipsis paired with -webkit-line-clamp handle long, unpredictable strings without custom JavaScript:

.card-title {
 overflow-wrap: break-word;
 display: -webkit-box;
 -webkit-line-clamp: 2;
 -webkit-box-orient: vertical;
 overflow: hidden;
}

If you're pulling content from a CMS into a React or Next.js component, sanitize pasted HTML on the way in rather than trusting the editor's output. A library like sanitize-html or DOMPurify strips inline styles and disallowed tags before they reach your component tree. That stops a stray <font> tag from silently overriding your design tokens.

Break Your Own Layout on Mobile Before a User Does

Responsive design bugs rarely show up on the breakpoints you tested. They show up in the gaps between them. A component that looks fine at 375px and 768px can fracture at 620px, especially once you drop in real content instead of placeholder text. We cover related ground in how to detect node.js event loop lag in production explained.

Run through this mobile-specific pass:

• Test at odd, unofficial widths (600px, 690px, 820px), not just your design system's named breakpoints.
• Check every sticky header, modal, and bottom sheet with the on-screen keyboard open. Keyboards frequently push fixed-position elements off-screen or trap focus in unreachable inputs.
• Rotate the device. Landscape mode on a phone is a genuinely different layout problem than portrait, and it's the one QA pass most teams skip.
• Rapid-tap every submit button on a throttled connection. Debounce or disable buttons on click to prevent duplicate form submissions when a network response lags.

That last one matters more than it sounds. A slow 3G connection combined with an impatient user tapping "Submit" five times can trigger five API calls before the first response returns. A simple disabled state solves it:

function SubmitButton({ onSubmit }) {
 const [isSubmitting, setIsSubmitting] = useState(false);

 async function handleClick() {
 if (isSubmitting) return;
 setIsSubmitting(true);
 await onSubmit();
 setIsSubmitting(false);
 }

 return (
 <button onClick={handleClick} disabled={isSubmitting}>
 {isSubmitting ? "Submitting..." : "Submit"}
 </button>
 );
}

Use Chrome DevTools' network throttling set to "Slow 3G" for this pass. It's the fastest way to expose race conditions that never appear on office WiFi. See full coverage of free vs paid ai api hosting: when to upgrade tiers for additional background.

Fix the Semantic HTML Gaps That Cost You Rankings

Search crawlers don't render your site the way a human does. They parse structure, and a <div> styled to look like a heading tells a crawler nothing about hierarchy or importance. This is the most common technical SEO bug in production codebases, and it's entirely preventable at the component level.

Audit your markup for these patterns:

• Every page has exactly one <h1>, and heading levels descend in order (h2 after h1, h3 after h2) without skipping levels for styling convenience.
• Interactive elements use native <button> and <a> tags instead of a <div> with an onClick handler. Screen readers and crawlers both depend on this.
• Landmark elements like <nav>, <main>, <article>, and <footer> wrap the appropriate sections instead of generic <div> containers everywhere.
• Every <img> has meaningful alt text, not a filename or an empty string, unless the image is purely decorative.

Run your production build through Lighthouse's accessibility and SEO audits, not just performance. A component library that looks visually correct can still score low because a card that behaves like a link uses a <div> with a click handler instead of an anchor tag.

Optimize Images and Ship Structured Data, Not Just Pretty Pixels

An unoptimized hero image is one of the fastest ways to tank Core Web Vitals, and Google has treated page experience as a ranking signal for years now. If you're on Next.js, the built-in Image component handles responsive sizing, lazy loading, and format conversion automatically, but only if you use it correctly:

Also read: see redora vs nestjs-redis: which redis tool fits nestjs?

import Image from "next/image";

<Image
 src="/hero.jpg"
 alt="Team collaborating on a product launch"
 width={1200}
 height={630}
 priority
/>

Set priority only on above-the-fold images. Marking every image as high priority defeats the purpose of lazy loading and can actually worsen your Largest Contentful Paint score.

Beyond images, structured data (schema markup) tells search engines exactly what your page represents, whether that's an article, a product, or a FAQ. Drop a JSON-LD block into your page's <head> and you've covered most use cases:

<script type="application/ld+json">
 {JSON.stringify({
 "@context": "https://schema.org",
 "@type": "Article",
 headline: post.title,
 datePublished: post.publishedAt,
 author: { "@type": "Person", name: post.author },
 })}
</script>

Validate every schema block with Google's Rich Results Test before deploy. A single missing required field can disqualify the entire markup from generating rich results, and that failure won't show up in your regular test suite.

The Final Pre-Deploy Pass

Before you merge to production, run this five-minute pass in order: paste real content into every dynamic component, resize the viewport through at least three non-standard widths, throttle the network and rapid-click every button, run Lighthouse for both SEO and accessibility scores, and validate any schema markup you've added. None of these steps require a dedicated QA hire. They require treating content chaos, mobile edge cases, and crawler behavior as first-class inputs, the same way you'd treat a malformed API response.

The teams that skip this pass aren't shipping faster. They're just moving the bug discovery from staging to a support ticket, or worse, to a page that never ranks because Google couldn't parse it. Building resilient components and clean semantic markup from the start costs a few extra minutes per feature. Finding out in production costs a lot more.