Launch operations
Publication migration readiness checklist
Organization byline: Measurement Press editorial desk. This page does not list an individual author or reviewer. Read the editorial method and corrections policy.
About 13 min read
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.
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.
| Decision | Ready record | Risk if missing |
|---|---|---|
| Final domain and route map | Canonical 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 boundaries | Business 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 inventory | List 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 policies | Privacy, 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 setup | Placement 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 baseline | Pre-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 state | Migration action | Test before launch |
|---|---|---|
| Same article, new host | Permanent 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 slug | Permanent 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 replacement | Redirect to the closest topic, guide, or updated article and record the reason. | Reader intent still makes sense after the redirect. |
| Retired article with no replacement | Return 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 changed | Redirect old archive route to the matching topic or library index. | Pagination, breadcrumbs, and ad slots still use the final route map. |
| Campaign landing route changed | Redirect 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.
| Area | Ready evidence | Decision rule |
|---|---|---|
| Placement map | Every 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 labels | Advertisement 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 paths | Serving 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 authorization | ads.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 keys | Package 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 baseline | Pre-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. |
Use one continuity test before launch
Run the same sample article through every handoff. Record the expected result before testing so a green page load does not hide a missing analytics event, seller path, feed entry, or reader-facing policy.
| Path | What to test | Evidence to keep |
|---|---|---|
| Reader | Old link, new link, mobile layout, search result, and related-guide path. | Final URL, title, readable body, and no broken task. |
| Search | Canonical, redirect status, sitemap, robots, feed, and internal links. | Route sample with expected indexability state. |
| Measurement | Page view, consent state, campaign parameters, conversion handoff, and baseline comparison. | Event payload and prelaunch baseline window. |
| Advertising | ads.txt, seller path, ad labels, layout stability, and policy/contact routes. | Account owner, request IDs, and rendered-slot evidence. |
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.
Prelaunch test matrix
| Surface | Test | Pass condition |
|---|---|---|
| Homepage and navigation | Open 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 templates | Open 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 files | Regenerate sitemap, feed, and search index after final route changes. | New and retired pages appear correctly, and no generated file points to an unavailable page. |
| Ads | Render each public ad slot family and compare it with the placement map. | Slot IDs, labels, sizes, and report keys match the inventory readiness record. |
| Redirects | Sample old article, archive, policy, campaign, and feed URLs. | Each URL reaches the right final page or a useful retired-page response. |
| Measurement | Trigger 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 field | What to capture | Why it matters |
|---|---|---|
| Timestamp | When DNS, route, template, feed, sitemap, ad, seller, or analytics changes went live. | Creates a comparison boundary for traffic, revenue, and reporting shifts. |
| Owner | Who made the change and who can approve rollback or repair. | Shortens launch-day debugging and prevents unclear ownership. |
| Changed surface | Domain, redirects, robots, sitemap, feed, canonical, ad config, analytics tag, or campaign destination. | Helps teams find the likely cause of a break. |
| Observed effect | Broken route, missing page, changed metric, ad suppression, speed shift, or search/referral change. | Separates migration effects from editorial, audience, or campaign effects. |
| Decision | Accept, 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.
| Area | 0 points | 1 point | 2 points |
|---|---|---|---|
| Canonical routes | Mixed 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. |
| Redirects | Old 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 files | Sitemap, feed, or search index is stale. | Generated files exist but need spot checks. | Generated files were rebuilt and validated after final route changes. |
| Ad readiness | Slots, 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 continuity | Events, 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 pages | Policy, 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 score | Status | Next action |
|---|---|---|
| 11-12 | Ready for cutover | Launch with the migration log open and post-launch checks scheduled. |
| 8-10 | Ready with constraints | Launch only the ready page groups, and hold weak ad or campaign surfaces. |
| 5-7 | Hold for repair | Fix canonical, redirect, generated-file, ad, or analytics gaps before public cutover. |
| 0-4 | Rebuild the plan | Do not migrate monetized or high-traffic pages until ownership, routes, and measurement are clear. |
Source boundary for a migration decision
Use first-party platform documentation for the mechanics, then keep the publication's own launch record as the evidence of what actually happened. Google Search Central's site-move guidance calls for an old-to-new URL map, self-referencing canonicals on the new URLs, updated internal links and sitemap entries, direct permanent redirects, redirect testing, and post-launch monitoring. It also warns against sending unrelated old URLs to one destination. The Search Console Change of Address tool is for a domain or subdomain move after the redirects are in place; it is not the right tool for an internal path change or a hosting/CDN change with no visible URL change. For ad continuity, the Google Publisher Console guide identifies the ad-unit path, container, slot size, targeting, and page-request timeline as inspectable fields.
Use boundary: these sources define checks and platform behavior; they do not prove that a fictional score below is a real migration result. The launch owner still needs the route map, rendered-page samples, redirect responses, generated-file copies, event payloads, and ad-slot evidence for the specific publication.
| Verified source | What it supports here | What still needs local evidence |
|---|---|---|
| Google Search Central: site moves | Map old URLs to specific new tasks; update canonicals, internal links, and sitemaps; use direct permanent redirects; test and monitor the move. | The publication's route map, redirect responses, final rendered pages, generated files, and post-launch Search Console data. |
| Search Console: Change of Address | Use the tool for a domain or subdomain move after redirects—not for an internal path change, same-domain www change, or hosting/CDN change with no visible URL change. | Which move occurred, which properties are verified, and whether all old and new variants have been redirected and tested. |
| Google Publisher Console | Inspect the ad-unit path, container, slot size, targeting, and page-request timeline when diagnosing a rendered ad path. | Actual placement IDs, labels, sizes, seller records, request results, and a reader-safe decision about whether a slot is ready to monetize. |
Source-to-decision rule: a platform document can define the test or explain an observed field; it cannot certify this publication's migration, ad delivery, revenue continuity, or reader outcome. Record the local artifact beside each gate and downgrade the decision when that artifact is missing.
Simulated Worked Example: decide whether the cutover is ready
This is a Simulated Worked Example, not a real migration or benchmark. The figures are fictional and show how to reproduce a go/no-go review. Replace them with the actual route map, test logs, rendered evidence, and owner sign-offs before using the decision in a launch record.
Suppose a migration packet contains 10 equivalent article routes, four generated files, eight measurement events, and six monetized slot records. The reviewer scores each check only when the evidence is present and tied to the final route or placement.
| Gate | Passed | Possible | Calculation | Readout |
|---|---|---|---|---|
| URL map and intent match | 10 | 10 | 10 / 10 = 100.0% | Every sample old URL has a specific final task. |
| Canonical and internal-link agreement | 9 | 10 | 9 / 10 = 90.0% | One sample still points to the pre-move host. |
| Direct redirect tests | 8 | 10 | 8 / 10 = 80.0% | Two samples need a direct final destination. |
| Generated sitemap, feed, search, and route files | 4 | 4 | 4 / 4 = 100.0% | All four copies contain the final route set. |
| Measurement event continuity | 6 | 8 | 6 / 8 = 75.0% | Two events lose a route or campaign field. |
| Ad path, label, size, and report fields | 5 | 6 | 5 / 6 = 83.3% | One slot lacks a complete placement record. |
Overall score: (10 + 9 + 8 + 4 + 6 + 5) / (10 + 10 + 10 + 4 + 8 + 6) = 42 / 48 = 87.5%. That percentage is a triage summary, not a launch clearance. Because canonical agreement, direct redirects, measurement continuity, and one monetized placement are still incomplete, the decision is hold the cutover and repair the evidence packet.
Critical-gate rule: do not average away a failure in URL intent, canonical destination, direct redirect behavior, or a monetized slot's identity and label. A bounded launch note can say, “The simulated packet scored 87.5%, but cutover is held because two redirect samples, two event fields, and one ad placement remain unresolved.” It should not say the migration is ready because the aggregate score is above a chosen threshold.
Reproduction and sensitivity check
To reproduce the score, copy each passed and possible count into a worksheet, sum the passed column, sum the possible column, and divide the first total by the second. Keep the gate names beside the arithmetic so a strong generated-file check cannot hide a broken redirect or ad record.
| Scenario | Passed / possible | Score | Decision effect |
|---|---|---|---|
| Base simulated packet | 42 / 48 | 87.5% | Hold: critical route, event, and placement gaps remain. |
| Repair the two redirect samples only | 44 / 48 | 91.7% | Still hold: canonical, event, and ad evidence are incomplete. |
| Repair every critical gate | 48 / 48 | 100.0% | Eligible for a bounded launch review, not proof of post-launch success. |
The sensitivity rows are not forecasts and do not establish a pass threshold for every publication. They show why a migration record should preserve gate-level evidence, assumptions, unresolved owners, and the exact changes that would alter the decision. After launch, compare old and new properties separately in Search Console and monitor analytics, redirects, errors, and ad diagnostics rather than treating the first post-move change as causal proof.
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.