Stop Estimating Site Migrations by URL Count: A Guide to Entity Preservation

When you ask how many hours you should estimate for a site migration, the answer should never be a flat rate. In my experience, the complexity of the data structure is a much larger factor than the volume of pages. For example, a migration involving a domain change requires significantly more hours than a simple CMS move on the same domain.

This is because you are asking Google to transfer its understanding of your brand entity from one digital location to another. In practice, I categorize migration hours into three distinct buckets: Pre-Migration Architecture, Execution, and Stabilization. If you are working in a regulated vertical, you must also include a fourth bucket: Compliance Review.

Each of these stages has its own set of variables. A site with a high degree of technical debt (old scripts, broken redirects from previous moves, messy schema) will require 30-50 percent more hours in the pre-migration phase just to clean the slate. I have found that the most reliable way to estimate is to look at the unique templates rather than the total page count.

Mapping redirects for 1,000 blog posts that all follow the same structure is a 5-hour task with the right tools. However, mapping 50 service pages that each have unique conversion goals, specific author citations, and complex internal linking structures can take 20 hours or more. This is where the Precision-Mapping Protocol comes into play: we treat every high-value URL as a standalone project to ensure no authority signals are lost in the move.

The first 15 to 30 hours of any migration should be spent on what I call The Blueprinting Phase. This is where we establish the Reviewable Visibility baseline. You cannot know what you have lost if you do not have a perfect record of what you started with.

This involves more than just a Screaming Frog crawl. It requires a deep-dive into Google Search Console data, backlink profiles, and entity signals. During this phase, I use a process called the Signal Decay Audit.

We identify the pages that are currently 'carrying' the site's authority. In many cases, 80 percent of a site's visibility is driven by 20 percent of its pages. We must document the exact state of these pages: their metadata, their internal link count, their outbound links to other authoritative sources, and their schema properties.

This documentation ensures that the new version of the site is at least as strong as the old one. What I've found is that clients in financial services or healthcare need a documented trail of these decisions. We provide a Migration Blueprint that outlines every intended change.

This phase also includes the Technical Staging Review. We set up a staging environment that mirrors the new site structure and perform a full audit before a single person from the public sees it. This prevents the 'launch and fix' mentality that often leads to long-term ranking declines.

If you skip this, you will likely spend 3x the hours later trying to recover lost ground.

Redirect mapping is where most SEOs lose their way. They use automated tools to match old URLs to new URLs based on the closest string match. In my experience, this is a recipe for relevance loss.

If the new site has a different information architecture, a simple string match might point a specific, high-intent page to a generic category page. This signals to Google that the specific expertise of the original page has been removed. I use the Precision-Mapping Protocol, which categorizes URLs by their intent and authority weight.

For high-value pages, we manually verify the destination. If a page is being consolidated, we ensure that the content from the old page is actually represented on the new destination. This is critical for maintaining topical authority.

If you move a page about 'Commercial Litigation in New York' to a general 'Legal Services' page, you will lose the specific geographic and niche signals that were helping you rank. For a mid-sized site of 500 to 1,000 pages, you should estimate between 10 and 20 hours specifically for redirect mapping and validation. This includes the time to write the regex rules for bulk redirects and the time to manually check the top 100 most important URLs.

We also include time for 404 strategy. Not every page should be redirected: sometimes, a clean break is better for the overall crawl budget of the site. Deciding which pages to kill and which to save is a strategic decision that requires senior-level oversight.

In the current search environment, Google is looking for entities, not just keywords. When you migrate a site, you are essentially moving an entity. If you change the names of authors, the structure of your About Us page, or the way your organization is described in LD+JSON schema, you risk confusing the search engine.

I developed the Entity Continuity Protocol (ECP) to address this specific risk. The ECP focuses on the signals of trust that surround your content. This includes ensuring that Author Schema remains consistent across the move.

If a doctor's profile URL changes, we must ensure that all their published articles now point to that new URL and that the doctor's own SameAs properties (linking to their LinkedIn, medical board profiles, etc.) are updated. This is a meticulous process that often requires 10-15 hours of manual work for sites with multiple contributors. What I've found is that regulated industries are particularly sensitive to these changes.

A bank or law firm relies on the established authority of its partners. If the migration breaks the link between the partner's name and their professional accolades, the site's visibility can suffer. We estimate hours for a full Schema Audit post-migration to ensure that the Knowledge Graph connections remain intact.

This is not just technical SEO: it is digital reputation management via code.

The 48 hours before a migration goes live are the most critical. I recommend estimating at least 10 to 15 hours for Technical QA during this window. This is where we verify that the staging site is actually ready for production.

We check for common 'migration killers' like noindex tags that were left on by developers, broken canonical tags, and incorrect hreflang implementation for international sites. In my practice, I use a documented workflow for this QA process. We run a full crawl of the staging site and compare it to the production crawl.

We look for discrepancies in page titles, header structures, and internal link counts. If the new site has significantly fewer internal links pointing to a key service page than the old site did, we flag it. This is a Reviewable Visibility step: we provide the client with a 'Go/No-Go' report based on these technical findings.

We also test the server response times. A new CMS or a new hosting environment can often be slower than the old one. If the Core Web Vitals take a hit during the migration, it can negate any SEO benefits the move was supposed to provide.

We allocate time to work with the development team to optimize TTFB (Time to First Byte) and image compression before the site goes live. This is especially important for mobile-first indexing, where performance is a direct ranking factor.

The work does not end when the site goes live. In fact, the first 90 days post-migration are when the most important visibility signals are processed by Google. I recommend estimating 20 to 40 hours for Post-Migration Stabilization.

This time is used for daily monitoring of Google Search Console for crawl errors, indexation issues, and ranking fluctuations. During this period, I look for Signal Decay. If a page was ranking in position 3 and drops to position 12, we investigate why.

Is the content different? Is the internal linking weaker? Is the page taking longer to load?

We use a Compounding Authority approach to fix these issues immediately. We might add additional internal links or update the content to better match the current search intent. This proactive approach prevents a temporary dip from becoming a permanent loss.

Another critical task in this phase is Backlink Reclamation. We reach out to the most authoritative sites linking to the old domain and ask them to update their links to the new URLs. While the 301 redirects handle the traffic, a direct link is always more powerful for PageRank transfer.

We prioritize these based on the authority of the linking domain. This is a manual, time-consuming process, but it is one of the most effective ways to solidify a new domain's authority in the eyes of search engines.

If you are migrating a site in a YMYL (Your Money or Your Life) industry, your hour estimates must be different. In legal, healthcare, and financial services, the cost of an error is not just lost traffic: it can be a regulatory violation. For these clients, I use a much higher multiplier for my hour estimates.

This is because every redirect, every meta tag change, and every schema update must be documented and reviewable. In my experience, you should add at least 40 percent more hours for documentation and meetings. You will likely be working with a legal team that needs to understand exactly why a page title is being changed.

You will need to provide audit trails for every change made to the site's architecture. This is part of the Reviewable Visibility philosophy: we don't just make changes; we document the rationale, the implementation, and the expected outcome. Furthermore, these industries often have complex disclaimers and licensing information that must be present on every page.

If a migration accidentally strips a required legal disclaimer from the footer of a thousand pages, the firm could face serious consequences. We allocate specific hours for a Compliance Audit post-migration, where we manually check a sample of pages across all templates to ensure all required legal elements are intact. This level of detail is why a 'cheap' migration is never actually cheap for a regulated business.