Make the site easier to crawl. Plan what changes.

A technical review establishes which pages should appear in search and what prevents that from happening. Crawlability means a search engine can request a page. Indexation means the engine has included it in its index. A page can satisfy the first condition without satisfying the second.

• Review status codes, broken links, unexpected redirects and pages excluded from indexing.
• Check robots.txt crawl rules alongside page-level indexing directives. They serve different purposes.
• Review XML sitemaps for intended canonical URLs, missing priority pages and outdated destinations.
• Prioritize findings by the pages affected, the likely consequence and what a developer needs to change.

Navigation, page hierarchy, breadcrumbs and internal linking should make the relationships between topics clear. An important page needs a useful place in the site and links from related pages. An orphaned page can exist in a sitemap while remaining difficult for a reader to discover.

Duplicate content can arise from URL parameters, archives or several addresses showing the same page. Canonical tags identify a preferred version; redirects and internal links should support that choice. Thin content needs a separate editorial decision: improve, consolidate or retire it according to its purpose. On large sites, unnecessary URL variants can waste crawl budget, the crawling attention available to the site.

Template problems repeat across every page that uses them. The review covers heading structure, metadata fields, content placement, structured data and the mobile experience, alongside site speed. Core Web Vitals describe loading, responsiveness and visual stability through LCP, INP and CLS. Their findings need to become specific implementation tasks.

A CMS change can alter image handling, scripts, caching and rendering. A headless CMS separates content management from the website that displays it, so the rendered output needs its own checks. Search-critical content, links and metadata must remain available in the delivered page. Requirements are written for the actual build and reviewed against representative templates.

A migration changes the addresses, structure or delivery of an existing site. Triggers include a rebrand and domain change, a CMS replatform, URL restructuring, moving from HTTP to HTTPS, consolidating several sites, or separating one property into several. A hosting change needs a narrower review when URLs and content stay the same.

URL mapping records the decision for each known old address before redirects are implemented. A 301 redirect indicates a permanent move. Its destination should be the relevant replacement page. Existing redirect chains also belong in the map so historical addresses can resolve directly to the final destination. Pages without a meaningful replacement need an explicit retirement decision.

QA in the staging environment tests priority pages and shared templates against the written requirements. The record shows what was checked, what failed and what needs another review before launch.

• Test redirect destinations and identify chains, loops or missing rules.
• Check canonicals, internal links, titles, headings and structured data against the new URL structure.
• Confirm which staging access restrictions must change for production.
• Review sitemaps, analytics configuration and page-speed regressions, allowing for differences between staging and live infrastructure.

Launch adds evidence that staging cannot provide: real crawler access, production redirects, live measurement and changing indexation. Post-migration monitoring compares those signals with the dated baseline. Search performance can fluctuate as engines process a move; a traffic change needs investigation before it is assigned a cause.

Search reporting systems such as Google Search Console and Bing Webmaster Tools show indexing and search activity. An analytics system such as Google Analytics helps examine visits and conversion paths. Used together, those categories of evidence help distinguish missing measurement from lost visibility. Findings go to the team responsible for correction, with affected URLs and a way to verify the fix.