DEV Community: Dale

I QA'd Samsung.com Launches for 5 Years. Here's My Pre-Launch Audit Process.

Dale — Mon, 28 Sep 2026 20:22:17 +0000

A website launch has exactly one moment where everything has to work at once. The DNS cutover happens, traffic arrives, and every mistake your team made in the last three months becomes public simultaneously.

I spent five years in digital content operations at Samsung, running pre-publish QA and launch support for Samsung.com. I've been the person staring at a staging environment at 11 PM the night before a launch, working through a checklist, knowing that whatever I missed would be live by morning.

Here's the process I used. It works on any CMS, any site, any team size — including a team of one.

Why launches break

In my experience, launches don't break because of one catastrophic bug. They break because of twenty small things nobody checked:

A hero image that looks perfect on desktop but crops someone's face out on mobile
A product page linking to a PDF that 404s
Meta descriptions that are still "Lorem ipsum" from the template
An analytics tag that fires on staging but was never added to production
A "Buy now" button that works in Chrome and does nothing in Safari

Each one is trivial. Together, they're a launch-day disaster. A process beats heroics.

The process, step by step

1. Freeze the content

Before you QA anything, get a content freeze. No new pages, no edits, no "just one quick change." Every change after the freeze invalidates the checks you already ran. In Jira, I marked the freeze as a hard status change so the whole team could see it. If your team won't agree to a freeze, scope your audit to a snapshot and note the timestamp — at least you'll know what you actually checked.

2. Crawl the staging site

Run a crawler (Screaming Frog's free tier covers 500 URLs) and export everything. You're looking for:

Broken links — internal and external. External links rot constantly; check every one.
Redirect chains — especially after a migration. A chain of three redirects is a page that loads slowly for no reason.
Missing or duplicate titles and meta descriptions — template leftovers are among the most common findings I've seen.
Images over 500KB — page speed killers. Flag them for compression.
Orphan pages — pages with no internal links pointing to them. If nothing links to it, users can't find it, and neither can search engines.

This one step surfaces more issues than any other single check. It's also the step most teams skip because "we'll check manually." You won't. Crawl it.

3. Walk the money paths

Identify the 3–5 pages that matter most — homepage, top product pages, checkout or contact flow — and test them by hand, end to end, like a user would:

Fill out every form. Submit it. Confirm the confirmation page loads and the email actually arrives.
Click every CTA. On every browser you support.
Test on a real phone, not just responsive mode in dev tools. Real phones have real rendering quirks.

I call these the money paths because if they're broken, nothing else matters. A perfect blog archive doesn't save a broken checkout.

4. The device and browser matrix

You don't need 40 devices. You need the ones your analytics say your users have. At minimum:

Chrome and Safari on desktop
Safari on iPhone, Chrome on Android
One tablet view

Check layout, navigation, and forms on each. Take screenshots. An outsized share of the issues I found lived in exactly one place: Safari on iOS, usually a flexbox or video autoplay issue.

5. SEO and analytics spot-check

Is there a robots.txt? Does it block staging but allow production? (Getting this backwards is one of the most expensive mistakes you can make on launch day.)
Are canonical tags present and correct?
Is the analytics/GTM container on every template, including the new ones?
Are 404 and 500 pages branded, or are they server defaults?

6. Accessibility basics

You don't need a full WCAG audit before launch, but check the cheap wins: alt text on images (especially linked images), keyboard navigation on the main menu, color contrast on body text, and form labels. These take an hour and prevent the most embarrassing findings.

7. The go-live checklist

The night before, verify the boring infrastructure stuff:

DNS cutover plan and who owns it
SSL certificate installed and forced (http → https redirect working)
Staging environment locked or de-indexed so it doesn't compete in search
Rollback plan — who decides, how fast, and what's the trigger
Who's on call for the first 24 hours

How long does this take?

For a site under 100 pages: about two days, solo. Day one is the crawl and the money paths. Day two is browsers, SEO, accessibility, and writing up the findings. For a 1,000-page site, add a day for triage and prioritization.

The deliverable is a prioritized list: blockers (fix before launch), should-fix (fix this week), and nice-to-have (backlog). No launch I've ever worked had zero findings. The goal isn't perfection — it's knowing what's broken before your users do.

The part nobody wants to hear

The process only works if someone actually runs it. On most teams, launch QA is everyone's responsibility, which means it's nobody's. The single highest-value thing I did on launches wasn't finding bugs — it was being the person whose job it was to look.

If you're launching a site and you don't have that person: that's the gap.

I do pre-launch website audits for agencies and site owners — the full process above, delivered as a prioritized findings report in 5–7 days. If your launch is coming up, drop a comment and I'll walk you through what an audit would cover for your site.

5 AEM Publishing Mistakes That Break Launches

Dale — Sun, 27 Sep 2026 14:25:08 +0000

If you read my last piece, you know I'm big on the pre-publish QA checklist. That checklist exists because I've watched every one of these mistakes happen on real launches — including weeks where the whole team worked overtime to hit the date anyway.

Here are the five I see most often.

1. Publishing without confirming the cache actually cleared

You hit publish, the page looks right in Author, and you move on. Meanwhile the dispatcher is still serving yesterday's version to everyone else. On a launch day with coordinated timing, "it's live" turning out to mean "it's live for us" is a bad surprise.

The fix: after every publish, check the page in a fresh incognito window or from a device outside the network. Make it a line item, not a hope.

2. Links that broke when pages moved

AEM makes it easy to restructure — move a page, and the old URL either redirects or it doesn't. Multiply that by a launch with dozens of new and moved pages, and you've got a 404 minefield.

The fix: run the link checker before publish day, and re-run it after any late restructuring. The pages that moved at 4pm are the ones that break at 9am.

3. Metadata and alt text treated as optional

Title, description, alt text — the stuff that gets skipped when everyone's rushing. Then the launch is live, search listings look wrong, and screen readers hit a wall of "image."

The fix: make metadata part of the authoring template's required fields, not a separate step someone does later. Later never comes.

4. Nobody checked mobile

The authoring UI is a desktop experience. Authors build for the screen in front of them. Then launch day traffic — mostly phones — sees overlapping components and cropped hero images.

The fix: responsive preview is in the checklist for a reason. Check the two breakpoints your analytics say matter most, every time.

5. The page went live without sign-off

This is the process one. Someone publishes directly because the workflow felt slow, the approver was out, the deadline was real. Sometimes it's fine. Sometimes marketing sees a headline they never approved.

The fix: workflows only work if the path of least resistance goes through them. If people are bypassing approvals, the workflow is the problem — simplify it until going around it is harder than going through it.

Get the full playbook: I expanded this checklist into Adobe Experience Manager Simplified — 38 pages on AEM content operations: publishing lifecycles, governance, metadata, DAM workflows, Jira intake, launch runbooks, and 8 copy-paste templates I actually used. $39: https://davidverse176.gumroad.com/l/saaok

What would you add to this list? I read every comment.

The Pre-Publish QA Checklist I Wish I'd Had on Day One in AEM

Dale — Fri, 25 Sep 2026 02:47:37 +0000

Every item on this list exists because something broke in production.

I spent four years running content operations on a large AEM site. In that time, I watched a page go live with the staging cache still warm, a promo banner with last quarter's pricing, and a checkout link pointing at the author environment. Each one had the same root cause: someone eyeballed the page in author preview and hit publish.

Author lies. Publish tells the truth.

So I built a checklist. Not a theoretical one — a "this exact thing burned us" one. I ran it before every publish, and the production incidents dropped off a cliff. Here it is.

1. Content correctness

All copy matches the approved source document. No placeholder text, no lorem ipsum, no "TK."
Product names, prices, and specs match the source of truth.
Dates, times, and time zones are correct and clearly labeled.
Legal disclaimers and footnotes are present where required.
Critical: any pricing, offer terms, or claims have written stakeholder approval on file.

2. SEO and meta

Page title set, unique, under 60 characters. Meta description under 160.
Canonical URL correct — especially for campaign or duplicated pages.
Open Graph tags present for anything that will be shared.
One H1 per page, headings in order, no skipped levels.
Staging and test pages must NOT be indexable. Launch pages must be.

3. Links

Every link clicked and verified — internal and external.
No links to author-environment URLs. If you see /editor.html in a href, stop.
Critical: checkout, cart, and conversion-path links tested end to end.

4. Images and media

Every image loads at every breakpoint. No broken image icons.
Alt text on every meaningful image; decorative images marked decorative.
File sizes sane: heroes under ~300 KB, gallery images under ~200 KB. Check the actual rendition, not the original.
Correct rendition for each placement — no full-size originals in thumbnail slots.

5. Responsive and cross-browser

Check at mobile (~375px), tablet (~768px), and desktop (~1440px).
No horizontal scrolling. Text doesn't overlap anything.
Checked in your two most-used browsers (usually Chrome and Safari).

6. Accessibility basics

Color contrast meets WCAG AA for body text (4.5:1).
Form fields have visible labels, not placeholder-only text.
Page is keyboard-navigable: logical tab order, visible focus, no traps.
Videos have captions; audio has a transcript link.

7. Personalization and targeting

Targeting rules reviewed: which audiences see this, and is the logic right?
Default (untargeted) experience verified.
No audience sees content meant for a different audience. The classic: employees seeing the "new customer" offer.

8. Publishing mechanics

Content activated to the right publish environment — not just sitting in author.
Scheduled publishes have the correct date, time, AND time zone.
Dispatcher cache flushed for the changed pages — then verified by loading the page in a fresh session.
Critical: check on the live URL, not the author preview.

9. Analytics and tracking

Page views registering. Conversion events firing — test each one.
Campaign tracking parameters correct on promo links.
No duplicate page-view tags after template changes.

How to run this without it taking all day

For a major launch, run the full list — budget half a day. For routine updates, run the starred critical-path items plus whatever sections the change touches. A copy change needs sections 1–3. An image swap needs 4–5.

The rule: the checklist scales with the blast radius of the change. A homepage hero gets the full pass. A typo fix gets content correctness and a live-URL check.

And keep a QA log — ticket number, date, who ran QA, pass/fail, issues found. When something breaks in production despite QA, the log tells you whether the checklist failed or the checklist was skipped. Those are very different problems.

Want the full checklist as a playbook? This article is Chapter 6 of Adobe Experience Manager Simplified — my 38-page guide to running content operations in AEM: lifecycles, governance, metadata, DAM workflows, Jira intake, launch runbooks, plus 8 copy-paste templates. $39: https://davidverse176.gumroad.com/l/saaok

What's the worst thing that ever slipped past your QA? I read every comment.