Hiroshi.TEditor
A pre-launch SEO review should answer a practical question: is the site that will be released sufficiently complete, accurate and technically ready for people to use and for search engines to discover its intended pages? A polished prototype is not the same as a working website. Links can still point to staging, forms can fail outside the test environment, and important article sections can disappear when a production renderer uses different templates. A useful review prioritises risks that can still be corrected before launch and identifies checks that can only be completed once the public site is available. It does not attempt to turn every minor optimisation into a release blocker.
Set the release scope and a source of truth
Start with the agreed sitemap or page inventory, redirect decisions, important customer journeys, content approvals and known exceptions. Confirm which changes are in scope and which are separate future work. If a service page was deliberately postponed, do not report it as a forgotten launch defect; if a required contact route has disappeared, treat it as a real issue. The review should be grounded in a stable list of expected pages, roles and decisions rather than someone's recollection of the original brief.
Record who can approve changes and who will deploy them. The team that writes a technical finding may not control the live template. Define the process for communicating launch blockers, evidence, severity and verification requirements. A checklist without an implementation owner can create the appearance of control while the same fault remains in the final release.
Reconcile the planned and actual URLs
Compare priority pages against the intended URL structure. Identify renamed or removed paths, duplicate address variations and pages that exist only in the staging build. If an old website is being replaced, validate that important retired addresses have a clear redirect decision. The destination should represent the old page's purpose rather than send unrelated addresses to the new homepage.
Test representative URL patterns and the highest-value routes before expanding to edge cases. A migration mapping spreadsheet is useful but does not prove that web server rules behave as expected. Check protocol and hostname choices, trailing slashes and potentially conflicting routes only where they apply. Document anything that must be retested after the release because the staging host cannot reproduce the actual response.
Inspect content against the approved page purpose
Read important pages as a visitor who has not seen the brief. Does each page answer the question suggested by its heading and title? Are service offerings, eligibility, prices or guarantees actually true? A page may have plenty of paragraphs while still failing to explain the most important purchasing decision. Confirm that critical content has been reviewed by the people who know the underlying product or service.
Check whether copied placeholder copy, old brand references, unapproved testimonials, stock claims or temporary promotional dates remain in templates. Substantive text should be retained through implementation, including supporting examples, captions and comparison material. If an editor has approved an article with a table and FAQ, the preview should show those sections; a database field populated but not rendered publicly is not the same as a completed page.
Review titles, descriptions and headings
Each important indexable page should have a descriptive title reflecting its actual purpose. A meta description can help communicate that purpose but is not a guaranteed Google snippet. Check for repeated generic titles caused by a shared template and for headings that misrepresent the content. Do not force an exact keyword phrase into every heading or make identical location pages merely to expand the inventory.
Consider the relationship between title, visible H1, navigation label and canonical URL. They need not use identical wording, but they should describe the same real subject. If a page was changed from one service to another during the build, revisit its metadata instead of assuming the original plan still fits. When the technical owner controls these fields, send an exact correction rather than an ambiguous suggestion to optimise SEO.
Verify navigation and internal links
Use the website's actual menus, footers, breadcrumbs and contextual links. Make sure customers can find essential services, contact options, policies and supporting guides. Check links to important pages for incorrect destinations or unnecessary redirects. An article can exist in the CMS but be effectively undiscoverable if nothing relevant links to it.
Mobile navigation deserves separate attention. A menu can work with a desktop mouse but fail on touch or keyboard. Inspect whether the active navigation label is understandable and whether important content stays reachable when the layout collapses. Do not treat the presence of a sitemap as a substitute for functional navigation. Good internal links help users move between relevant pages and let crawlers discover accessible routes.
Check indexing, canonical and staging restrictions
Review robots directives, noindex instructions, canonical references and the intended treatment of duplicate or utility URLs. Development sites sometimes use restrictive settings that should not persist into public production. Conversely, not every staging page should become indexable when a launch begins. Agree which URLs are intended for search and inspect representative templates for the corresponding controls.
Where a page canonicalises to another address, confirm the decision and make sure the content relationship supports it. An incorrect global canonical can affect many pages, so verify several page types rather than only the homepage. If the team cannot inspect final HTTP headers until after deployment, record that limitation as an explicit post-launch check. A valid-looking plugin preview is not proof of a production response.
Confirm redirects and important response codes
Check planned redirects for critical existing URLs, with particular attention to changed services, products, articles and campaign destinations. Test both the target and the full route from the old address. Redirect loops, long chains and generic targets can create unnecessary friction. Remember that a page returning a normal response can still display the wrong content, so status-code verification is only one part of acceptance.
Keep an exception list where a retired page has no appropriate replacement and needs a deliberate alternative decision. Do not fabricate redirects to unrelated pages just to avoid a 404 metric. A genuine removal may require a different response from a moved page. Follow Google's guidance on site moves and redirects where the context applies.
Test forms and commercial interactions
A website can satisfy its page inventory and still fail commercially if visitors cannot contact the business. Test the main enquiry or buying paths, including validation and confirmation. Do not interpret clicking a submit button as proof that a message arrived. Confirm that the receiving team and system will actually process the request under an authorised test method.
Check mobile input behaviour, visible labels, error handling and whether forms collect only necessary personal details. If an external booking or payment provider is involved, define what can be tested safely before launch. Make sure the appropriate privacy information and operational contact routes are available. A launch blocker should reflect a real failed customer task, not merely a low synthetic score.
Check media sources and responsive presentation
Verify that important images have correct sources, permissions, attributions and useful alternative text. A file visible in an image search is not automatically reusable. When a Commons asset is used, inspect the original file page and note the applicable licence. Avoid suggesting that generic workplace photography depicts the actual business team unless evidence supports that claim.
Test layout at representative narrow widths including 320, 375 and 768 pixels. Important copy, forms and comparison tables should remain readable. Wide tables may use their own labelled scroll container rather than forcing the whole page sideways. Confirm that fonts, images, captions and third-party widgets do not cover contact controls. Actual public image responses must be checked after launch; merely storing an img tag is not a passing load test.
Review performance pragmatically
Look for severe loading problems on priority pages, especially oversized images, blocking scripts and layout instability. Core Web Vitals can guide investigation, but their scores do not replace testing of content and user tasks. A slow product page may warrant attention before a minor metadata improvement, while a nearly instant page with broken checkout still fails the commercial objective.
Reserve image dimensions to reduce layout shifts, defer suitable below-the-fold images, and avoid blanket lazy loading of content needed immediately. Document the environment and measurement limitations. Do not guarantee that a particular performance score improves rankings or conversions; the practical question is whether the page remains usable for its intended readers.
Prepare a bounded launch-blocker register
For each finding, record the affected page or shared component, expected behaviour, evidence, severity, owner, proposed change and final verification criterion. Distinguish a defect that blocks customer journeys or search access from an improvement that can enter routine work. Do not bury an accidental sitewide noindex setting beneath dozens of low-risk recommendations. Equally, do not stop a release because a nonessential heading could use different wording.
Agree who can accept residual risk. A content editor should not personally sign off a production security change, and a developer should not approve an unverified commercial claim. A short, evidence-led decision makes the launch safer and creates a useful handover record.
Plan what can only be verified after deployment
Some checks cannot pass until the real public host is serving the release. These include final URL responses, live redirects, public HTML content parity, third-party image delivery and customer-side interactions. Schedule them immediately after deployment and assign owners. A pre-launch review should state what it verified in staging and what remains awaiting production evidence rather than claiming a blanket full pass.
After deployment, compare visible title, body, tables, FAQ, author card and navigation against the approved records. If a renderer or cache returns old or incomplete content, investigate the content assembly path. Do not repeatedly rewrite correct source text as a substitute for fixing public delivery. Confirm that internal notes and drafting metadata are not printed to visitors.
Close the review with a launch handover
Summarise critical checks completed, accepted exceptions, unresolved dependencies, rollback ownership and post-launch monitoring. Keep evidence easy to revisit. A client or developer should be able to tell which page was checked, when, what result was observed and who accepted it. This avoids a vague claim that SEO was reviewed when key controls were never tested on the actual public site.
The best pre-launch SEO review reduces risks to useful pages and customer journeys without creating unnecessary delay. It asks whether the intended website is ready for real visitors, not whether an automated tool has produced a maximum score. Primary source A: Google Search Central site moves with URL changes. Primary source B: Google canonical URL guidance. Additional reference: W3C WCAG 2.2. These sources provide general standards, not a certificate that any specific website launch is ready.