Launch operations

Publication migration readiness checklist

A publication migration can look finished because the pages render. The harder question is whether readers, search engines, advertisers, analysts, and editors can still follow the same source trail after the domain, templates, feeds, ad paths, or measurement setup changes.

Use this checklist before a relaunch, domain move, template rebuild, or advertising stack handoff. It is written for publishers and operators who need the site to remain indexable, readable, monetization-ready, and measurable while avoiding inflated claims from broken historical comparisons.

Advertisement Launch-readiness unit.

Migration decision record

Write these choices down before the cutover window. The record should be short enough for editors, ad operations, analytics, and product owners to read from the same page.

DecisionReady recordRisk if missing
Final domain and route mapCanonical host, URL pattern, homepage route, article route, topic route, case-study route, and any retired paths.Search engines, feeds, ads, and campaign links may point to different versions of the same page.
Ownership boundariesBusiness owner, technical owner, analytics owner, ad-operations owner, and support contact for launch-day decisions.Credential, billing, seller, and measurement decisions drift into personal or legacy accounts.
Content inventoryList of live pages, retired pages, redirected pages, noindex pages, and pages held for editorial review.Thin, outdated, duplicate, or broken pages enter the public index.
Reader-facing policiesPrivacy, corrections, methodology, advertising, source library, contact, and sponsorship pages reviewed against the final site state.Trust pages describe an older publication setup or missing advertising boundary.
Ad and seller setupPlacement IDs, ad-unit paths, ads.txt status, package IDs, deal keys, labels, and seller records assigned to the right publishing account.Demand can serve through unclear paths, stale seller records, or unreportable inventory names.
Measurement baselinePre-migration traffic, revenue, speed, search, and campaign-reporting baseline windows named before launch.Post-launch changes get misread as product success, traffic loss, ad yield, or campaign lift without a fair comparison.

Canonical and indexability checks

1. Pick one canonical host.

Every public page should point to the same final host pattern. Check homepage, article, topic, search, media kit, feed, sitemap, and privacy routes for inconsistent canonical URLs.

2. Keep internal links on the final path.

Navigation, breadcrumbs, article cards, feed links, sitemap entries, ad destination examples, and source-library links should not depend on temporary hosts or route aliases.

3. Separate live pages from held pages.

Pages held for editorial, legal, ad-operations, or policy review should be excluded from public navigation and search files until the owner signs off.

4. Test metadata after rendering.

Titles, descriptions, Open Graph tags, structured data, canonical tags, and article dates should match the final page, not only the template defaults.

5. Rebuild the generated files.

Sitemap, feed, search index, and any guide-library index should be regenerated after route, title, date, or publication-status changes.

Redirect map

Redirects should preserve the reader's task, not only avoid a 404. When a page's purpose changes, route it to the closest durable replacement and keep a launch log for future debugging.

Old stateMigration actionTest before launch
Same article, new hostPermanent redirect to the same path on the final host.Old URL lands on the final canonical URL with title, description, and body intact.
Same article, new slugPermanent redirect from old slug to the new canonical article route.Article cards, sitemap, feed, and internal links use only the new slug.
Retired article with close replacementRedirect to the closest topic, guide, or updated article and record the reason.Reader intent still makes sense after the redirect.
Retired article with no replacementReturn a useful gone or not-found page with navigation to related desks.The page is absent from sitemap, feed, search index, and public article lists.
Archive or topic route changedRedirect old archive route to the matching topic or library index.Pagination, breadcrumbs, and ad slots still use the final route map.
Campaign landing route changedRedirect only when the new destination keeps the same offer and tracking purpose.UTM, source, creative, and campaign records still identify the original flight.

Ad and revenue continuity

Ad inventory should migrate as a set of named contracts: placements, packages, labels, seller paths, and readout fields. Do not treat a visible ad box as proof that the revenue setup is ready.

AreaReady evidenceDecision rule
Placement mapEvery public ad slot has a stable placement ID, format, accepted sizes, breakpoint behavior, and report key.Hold pages with unnamed or unreportable slots out of buyer-facing packages.
Ad labelsAdvertisement or sponsor labels remain visible on desktop, tablet, mobile, lazy-loaded, native, and post-content units.Do not ship paid modules whose label can separate from the unit.
Ad-unit pathsServing paths match the final publication name, desk, route group, and placement contract.A route migration should not create duplicate inventory names for the same reader context.
Seller authorizationads.txt, seller records, supply-chain fields, and partner instructions are reviewed after the final domain is active.Do not add speculative seller rows before an authorized partner provides the exact values.
Private marketplace keysPackage IDs, deal keys, placement IDs, and reporting fields survive into trafficking and campaign reports.Hold PMP activation when the readout can only show pooled delivery.
Floor and renewal baselinePre-migration fill, viewability, floor, sell-through, speed, and engagement baselines are recorded by placement group.Do not compare new-domain yield against old-domain yield without naming the migration window.

Analytics and measurement continuity

A migration changes the denominator. Treat the cutover as a known event in reporting so launch-day traffic, search shifts, ad changes, and campaign outcomes do not get promoted into unsupported performance claims.

Preserve event names

Keep pageview, guide search, article click, ad slot render, outbound click, lead, and subscription events stable unless a change log explains the break.

Name the baseline window

Record the pre-migration comparison window before launch, then separate the cutover week from steady-state reporting.

Retain campaign source fields

UTM values, placement IDs, creative IDs, package IDs, and destination IDs should remain visible after redirects and template changes.

Check feed and search referrals

RSS, sitemap, search console, newsletter, social, and partner links should resolve to the final canonical route.

Flag measurement breaks

Template changes, consent changes, event changes, ad path changes, and redirect changes should be visible in dashboards and readouts.

Protect causal language

Traffic, revenue, or lead changes around migration should be described as observed changes unless a comparison design supports stronger language.

Advertisement Migration QA unit.

Prelaunch test matrix

SurfaceTestPass condition
Homepage and navigationOpen primary nav, article library, case-study library, topic desks, search, media kit, privacy, and corrections pages.Every route loads, keeps the right canonical URL, and has no broken local links.
Article templatesOpen a long guide, a short guide, a media-bias page, and a measurement page across desktop and mobile widths.Headline, lede, tables, ad labels, breadcrumbs, and footer links remain readable.
Generated filesRegenerate sitemap, feed, and search index after final route changes.New and retired pages appear correctly, and no generated file points to an unavailable page.
AdsRender each public ad slot family and compare it with the placement map.Slot IDs, labels, sizes, and report keys match the inventory readiness record.
RedirectsSample old article, archive, policy, campaign, and feed URLs.Each URL reaches the right final page or a useful retired-page response.
MeasurementTrigger pageview, guide search, ad render, outbound click, and lead events in a test path.Events carry final route, source, campaign, placement, and device context where expected.

Launch-day log

Keep a plain log during the cutover. It should name changes that could affect search, traffic, ads, analytics, and campaign comparisons.

Log fieldWhat to captureWhy it matters
TimestampWhen DNS, route, template, feed, sitemap, ad, seller, or analytics changes went live.Creates a comparison boundary for traffic, revenue, and reporting shifts.
OwnerWho made the change and who can approve rollback or repair.Shortens launch-day debugging and prevents unclear ownership.
Changed surfaceDomain, redirects, robots, sitemap, feed, canonical, ad config, analytics tag, or campaign destination.Helps teams find the likely cause of a break.
Observed effectBroken route, missing page, changed metric, ad suppression, speed shift, or search/referral change.Separates migration effects from editorial, audience, or campaign effects.
DecisionAccept, fix forward, hold demand, remove page, update redirect, or rollback.Keeps public quality and buyer readiness ahead of launch momentum.

Scorecard

Score each area from 0 to 2 before the migration window. A low score in canonical, redirect, or ad-seller readiness should block public cutover for monetized pages.

Area0 points1 point2 points
Canonical routesMixed hosts, temporary links, or unclear route map.Most routes are final, with known exceptions.All public routes, canonical tags, sitemap rows, feed links, and internal links agree.
RedirectsOld URLs break or point to weak replacements.Core redirects work, but long-tail routes need sampling.Old routes map to durable replacements and retired pages are intentionally handled.
Generated filesSitemap, feed, or search index is stale.Generated files exist but need spot checks.Generated files were rebuilt and validated after final route changes.
Ad readinessSlots, labels, seller records, or package fields are unclear.Core placements work, with one documented hold.Placement map, labels, seller fields, packages, and report keys are ready.
Analytics continuityEvents, source fields, or baseline windows are missing.Core events work, but migration annotation is incomplete.Events, source fields, and baseline windows are preserved and annotated.
Reader trust pagesPolicy, methodology, corrections, or advertising pages describe an old state.Trust pages are mostly current with one pending detail.Trust pages match the final publication, business, and advertising setup.

Decision bands

Total scoreStatusNext action
11-12Ready for cutoverLaunch with the migration log open and post-launch checks scheduled.
8-10Ready with constraintsLaunch only the ready page groups, and hold weak ad or campaign surfaces.
5-7Hold for repairFix canonical, redirect, generated-file, ad, or analytics gaps before public cutover.
0-4Rebuild the planDo not migrate monetized or high-traffic pages until ownership, routes, and measurement are clear.

Pair with

Use this checklist with the inventory readiness matrix for placement contracts, the media kit for ad-unit paths and sizes, the programmatic inventory QA checklist for launch fields, the ad experience and page-speed budget checklist for reader-experience limits, the supply path transparency checklist for seller-path evidence, and the campaign data-layer spec for reporting continuity.

Takeaway

A migration is not only a technical cutover. It is a change to the comparison group readers, advertisers, and analysts will use when they judge the publication's traffic, revenue, credibility, and campaign outcomes.