Hiroshi.TEditor
When a redesign, migration or major website change goes live, the main task is no longer to review the proposed plan. It is to compare that plan with what users and search engines can actually access. A redirect rule can be correct in a spreadsheet and wrong on the server. A new template can look attractive while omitting important article content. A staging noindex instruction can reach production accidentally. A useful post-launch SEO checklist therefore verifies the published website, assigns ownership of defects and establishes when the release can enter normal operations. The goal is not to promise instant ranking improvements but to reduce avoidable risks to customers and discovery.
Establish what was supposed to change
Begin with the approved launch scope: affected hosts, important paths, retired URLs, template changes, content moves, forms, integrations and measurement events. Do not assess the new site against a vague memory of how the old site worked. Obtain the redirect map, list of critical journeys, release notes, rollback owner and any known exceptions. A small, verified list of important URLs is more useful than an enormous crawl report without a clear baseline.
Note the release date, time zone and relevant environments. If the site uses a content delivery network, multiple origins or regional deployments, record which path was actually changed. Some defects appear only when an outdated edge response is served. A saved database update establishes that a record exists; it does not prove the public template assembled that record correctly. Keep those evidence types separate from the beginning.
Test the customer journeys before less important warnings
Open the homepage, major service pages, important product or category pages and the contact or checkout path using normal site navigation. Can customers understand the offering and complete the intended action? Verify the destination after a link click, form submission or other safe test. A missing purchase button or broken enquiry form may demand immediate action even while other SEO checks remain unfinished.
Test both desktop and representative narrow layouts. A mobile navigation menu may point to old URLs after a redesign; a sticky overlay may cover a submit button; a change in form handling may show a success message without actually recording an enquiry. Assign the defect to the team that owns the functionality. An SEO team can identify the issue but should not claim repair based only on a proposed ticket.
Verify redirects against the migration decision map
Test important retired URLs and representative URL patterns using the public response. The destination should satisfy the old page's purpose rather than simply send everything to the homepage. Check for loops, long redirect chains, accidental temporary responses, broken destinations and incorrect protocol or hostname changes. A redirect that looks syntactically valid can still be commercially misleading if it sends a product category to an unrelated service.
Review query parameters and trailing-slash conventions only where the site's architecture makes them relevant. Confirm that old campaign and external links continue to lead somewhere useful, and update critical internal links to the intended new addresses instead of relying indefinitely on redirects. Google Search Central provides site-move guidance, but a checklist cannot replace testing actual URLs on the production host.
Check indexing instructions and canonical decisions
Inspect the live HTML and relevant HTTP headers for accidental noindex directives, canonical conflicts, unexpected redirects and restricted access. Verify whether the canonical points to the intended published URL. A staging hostname or a retired address accidentally referenced by a shared template can affect many pages. Do not assume that a plugin's green badge proves the final server response contains the expected directives.
Use a sample across page types, then widen the investigation if a shared template fault is suspected. A single unusual URL may be an intentional exception. A repeated wrong canonical across service and article templates suggests a broader release defect. Document the scope, expected behaviour and responsible owner before applying sitewide replacements.
Confirm key page content is actually visible
Compare the public page with the approved content. Check the title, H1, main article, meaningful images, internal links, supporting tables, FAQ and contributor information when those elements are part of the site's requirement. A database can contain all these fields while a renderer displays only one of them. If the public response shows a mixed old and new article, investigate content assembly, caching or deployment rather than blindly rewriting the approved database text.
Check for unintended exposure of editorial notes, draft commentary or internal identifiers. These should not be rendered as public content. Clearing one sensitive field may mitigate one article, but it is not a substitute for fixing a renderer that improperly selects internal metadata. Note what was actually seen in the public HTML, not just what a content-management preview displayed.
Review crawl paths and internal navigation
Follow priority navigation and contextual links after the release. Shared menus, related-article blocks, breadcrumbs and footers may continue using retired paths. Test whether links are crawlable and whether the label accurately describes the new destination. A technically successful redirect may conceal a stale menu but still impose unnecessary hops and make maintenance difficult.
Inspect orphaned important pages if a crawl or inventory indicates that they lost incoming internal links. Do not generate links solely to improve a numerical score; make sure each route serves an actual user task. Check navigation from relevant categories and articles rather than adding every page to a global footer. Where language or regional variants are involved, confirm that links lead to the intended market.
Confirm sitemap and robots behaviour
Verify that sitemap URLs reflect the current canonical inventory, return appropriate responses and do not list large numbers of redirected or intentionally excluded pages. Check robots.txt for accidental staging restrictions and understand that robots directives and noindex instructions serve different purposes. A sitemap submission is not proof of immediate indexing or a complete technical audit.
Use Search Console observations as supporting evidence over time, while inspecting the actual public resources when an issue arises. Search Console reporting can lag and may not show every type of defect as a convenient list. Do not claim a page was repaired solely because a feed or sitemap was accepted. Record which checks were performed against the public host and which still require search-system confirmation.
Check structured data and social previews carefully
A redesigned template may omit JSON-LD, generate invalid fields or attach organisation details to the wrong page type. Inspect representative output and compare it with visible truthful content. Syntax validity is not the same as eligibility for a search feature, and structured data cannot justify fictional reviews or services. Fix source templates rather than patching individual pages if the problem is shared.
Open Graph tags may also be stale after a release. Confirm that shared URLs, titles and images refer to the intended new page. Social services sometimes cache previews, so first determine whether the public HTML is correct before attributing an old preview to a cache. Maintain valid image rights and avoid showing a product or workplace photograph that is not the real subject of the page.
Verify analytics and important events
Confirm that the agreed measurement system can observe important journeys without creating duplicate events or losing consent controls. A redesign may replace a form, checkout button or thank-you page and silently break conversion tracking. Test authorised events, check their definitions and record limitations. A click on a button is not necessarily an accepted lead or completed sale.
Use measurement to detect meaningful changes after release, but avoid attributing every fluctuation to the migration. Seasonality, marketing spend, product availability and search-system changes may affect the same period. Capture the date of the launch and the configuration of relevant reports so later comparisons are interpretable. If tracking is broken, mark the data as incomplete rather than drawing confident conclusions from it.
Inspect performance and mobile usability
Image size, shared scripts, fonts and widgets can change during a launch. Examine representative pages, especially business-critical mobile journeys. Check layout stability, important visible content and whether deferred images still load when a reader scrolls. Core Web Vitals can guide investigation, but an aggregate score cannot establish that a page's specific form or menu works.
Inspect widths such as 320, 375 and 768 pixels, keyboard access, text zoom and focus behaviour for affected templates. A comparison table may need contained scrolling. A newly added banner can hide navigation or the first form field on a phone. Capture reproducible steps and affected URLs so developers can confirm a correction rather than debating vague reports of poor mobile SEO.
Separate critical incidents from routine improvements
Classify issues by impact and urgency. A payment failure, an inaccessible contact page or accidental noindex on a key section may require immediate coordinated action. A minor wording issue or a lower-impact warning may safely enter normal backlog work. Each finding should have a stable issue ID, evidence, page scope, proposed owner and clear acceptance criterion.
Keep a short critical-issue register during launch stabilisation. Escalate through existing incident procedures when customers are materially affected. Do not label a tool timeout as a website outage without corroboration. If a change requires rollback, record who is authorised to make that decision and which related deployments might be affected. Fixing the wrong layer in a hurry can introduce new problems.
Plan monitoring over the following days and weeks
Some defects are immediately visible, while others surface as caches refresh, search reports update or customers visit less common paths. Establish a review cadence appropriate to the size of the launch. Look for repeated 404s, unexpected redirect targets, template anomalies, missing conversions and unresolved customer complaints. Compare against the approved migration inventory rather than reacting to any isolated numerical movement.
Retest repaired items on the public host. A ticket closing in a project board is not the same as an accepted production repair. If only the database record changed, verify the renderer and cache path independently. Maintain communication with account owners so the client understands which findings are closed, held or awaiting approval.
Hand off into normal operations deliberately
Once major customer paths, search-facing controls, redirects and measurement have been checked, move remaining lower-priority items into normal delivery. Document outstanding risks and owners. Avoid keeping every page permanently in a launch incident state, but do not bury serious issues as routine recommendations. A short handover with evidence allows another developer or agency to understand why changes were made.
Preserve the original release map, accepted exceptions and verified fixes. A future migration or redesign will benefit from that record. This is particularly important for small teams where one person may handle content, SEO and vendor communication. Reliable post-launch checking is a process of confirmation and triage, not an endless increase in checklist items.
Source A: Google Search Central: site moves with URL changes. Source B: Google Search Central: canonical URL guidance. Additional reference: web.dev Core Web Vitals. These materials supply general implementation guidance, not evidence that any specific launch has passed live verification.