How Website Migration Can Damage SEO Even Without Changing URLs

Keeping the same URLs during a website migration does not guarantee that its search engine rankings will remain unchanged. Changes to page rendering, canonical links, internal linking, and HTTP responses can affect how search engines crawl, index, and understand a website's pages. During a migration, the way SEO-critical elements are generated and delivered may change, even if URLs and visible page content remain the same. For example, such changes may occur when migrating from WordPress to a headless architecture using Contentful and Next.js. In this case, the distribution of SEO responsibilities changes: instead of plugins, themes, and server configurations, CMS fields, frontend components, routing logic, and rendering settings become the key elements. These changes can lead to problems that are difficult to identify during a superficial review. For example, canonical links may disappear, navigation links may become inaccessible to crawlers, content may shift from the initial HTML to JavaScript rendering, and missing pages may return a 200 status code instead of a 404. To identify such issues, it is necessary to document the SEO functions provided by the previous platform, verify how they are implemented in the new system, and focus migration testing on the elements that have changed. Identify the SEO Functions Handled by the Previous CMS Before testing the new platform, it is necessary to document which technical SEO tasks are handled by the current system. Determine Where SEO Functions Are Now Implemented In WordPress, an SEO plugin may automatically generate canonical links, meta robots directives, XML sitemaps, and structured data. The website theme may be responsible for displaying breadcrumbs, pagination, and navigation links, while redirects and server responses may be managed at the application or server configuration level. After migrating to Contentful and Next.js, the distribution of responsibilities changes. The CMS primarily stores content and relevant fields, the frontend determines which data will be displayed on the page, and the application's logic and routing affect page states and HTTP responses. For example, a canonical URL value may be stored in Contentful, but the frontend must use it to generate the page metadata. If the corresponding field is not properly connected, the content will remain unchanged, but the canonical link may disappear or stop being displayed. Internal linking may also change. In WordPress, the website theme may generate menu items and recommended content blocks using standard HTML links. During the development of the new website, these components may be implemented differently. The page may look exactly the same externally, but this does not guarantee that search engines can access all important links. Therefore, it is necessary to inspect the generated HTML code and ensure that key pages remain accessible through links that search engine crawlers can follow. Page states also require special attention. For example, on the old platform, a deleted page may have correctly returned an HTTP 404 status. In the new application, custom fallback logic may be used: the system attempts to retrieve the requested route, cannot find the corresponding entry in Contentful, and displays a page-not-found message. If the application does not set the appropriate HTTP error status, the server may continue returning a 200 status code. As a result, users see a message indicating that the page cannot be found, but search engines interpret it as a successfully loaded page. Establish Baseline Metrics Before Migration Before transferring the website, it is necessary to record the initial state of its technical characteristics for the main page types and usage scenarios. For each representative URL, the following data should be collected: HTTP status codes and redirect behavior. Main content and important SEO elements present in the initial HTML code. Elements that appear after page rendering. Expected canonical URL values and robots directives. Structured data output. Important internal links. The behavior of pages that are unavailable, deleted, or contain no content. The sample of pages should reflect the actual website structure and account for different interaction scenarios. For example, for an ecommerce website, it is advisable to check: A standard product page. A product page for an item that is temporarily out of stock. A category page. A paginated category page. A page with active filters. For an informational or corporate website with a blog, the sample may include: An individual article. A blog category page. An author page. Archived content. The collected data will serve as a baseline for comparison. It will help determine which characteristics the new implementation needs to preserve and identify deviations after migration. Test the SEO Functions Whose Implementation Has Changed Once it has been established which functions and elements have been transferred to other parts of the system, it is possible to develop a testing plan for the new website version. Check Canonical Links and Structured Data If canonical links were previously generated by a WordPress SEO plugin and are now handled by the Next.js frontend, the expected and actual outputs should be compared across all page templates that use the same logic. Pages with non-standard states should also be taken into account, as their canonical URL rules may differ from those of the standard template. If structured data was previously generated by a plugin and is now produced by frontend components, the relevant templates and page states must be checked. Particular attention should be paid to shared implementation logic. A single error in a component used across multiple pages can be repeated across a large number of URLs. When checking Schema.org markup, it is also important to consider that losing valid structured data may affect eligibility for rich results in search. However, this loss alone does not necessarily lead to lower search rankings. Compare Page Rendering and Internal Links If the frontend architecture changes during migration, particular attention must be paid to how content is generated and displayed. For example, the main content of a page may previously have been included directly in the initial HTTP response. After moving to a new platform, some elements may be loaded through client-side JavaScript. In this case, it is necessary to compare the initial HTML code with the fully rendered page and identify which content elements, links, and SEO signals have changed their delivery method. The use of JavaScript itself is not a problem that needs to be eliminated. The important question is whether the new rendering configuration reliably exposes the content and signals that search engines are expected to process. It is also worth considering that different components of the same page may operate according to different principles. For example, the main article may be server-rendered, while recommended content blocks, pagination, or product information are generated later. Therefore, checking only whether the main content is present will not provide a complete picture of the website's condition after migration. For navigation elements, breadcrumbs, product cards, and recommended content blocks, it is necessary to inspect the links that are actually generated. Components built with modern frameworks can produce fully crawlable links when implemented correctly. Therefore, conclusions should not be based solely on the technology being used — the final HTML code must be inspected. Test Routing Across Different Page States Routing must be tested not only for standard pages but also for different usage scenarios. Regular article or product pages may function without errors, while non-standard states may be processed using different application logic. During testing, the following should be checked: Deleted pages. Products that are no longer available. Empty categories. Pagination pages beyond the available range. A sample of invalid URLs. For example, a discontinued product page may have returned a 404 status on the old platform. If the new frontend displays fallback content for a record that does not exist in the CMS but does not set the corresponding HTTP status, the URL's behavior will change even though its address remains the same. Testing the elements whose responsibilities have changed during migration helps make the quality assurance process more focused. It also makes it possible to determine whether an issue affects an individual page or results from shared logic used across a much larger number of URLs. Analyze Patterns Across Templates and Components During testing, it is important not only to record individual differences but also to look for patterns among them. Identify Issues in Shared Implementations Suppose the expected canonical link has disappeared from one product page after migration. Before treating this as an isolated error, it is necessary to check other URLs that use the same template. If the same issue occurs across all such pages, its cause is most likely related to the shared template implementation. Similar patterns can also occur in shared website components. For example: A recommended content component may change internal linking across all page types where it is used. Configuration settings for a specific language version may affect hreflang output across all pages in the corresponding market. A pagination component may behave differently depending on the page type. Fallback logic for unavailable products may affect all URLs that enter the same state. For systematic analysis, issues should be classified according to the following parameters: Page template. Component. Page state. Language version or locale. Rendering method. This approach helps identify the shared part of the implementation responsible for the issue. Group Issues to Diagnose and Prioritize Fixes Consider a situation in which a website crawl identifies that 12,000 product pages no longer contain Product structured data after migration. If all affected URLs use the same product page template, the shared structured data implementation should be investigated. If the issue affects only products that are temporarily or permanently unavailable, it is worth examining the logic responsible for handling that particular state. If the error occurs only in one language version of the website, the configuration for the corresponding market should be reviewed. Grouping issues makes it possible to formulate more precise tasks for developers and determine the priority of fixes. For example, five pages with errors in manually entered metadata and 30,000 pages with incorrect canonical links may appear in the same website crawl report. However, the scale of these issues and their likely causes differ significantly. Grouping also helps after the new website goes live. If indexing or organic performance changes, specific URL groups can be analyzed instead of relying solely on general website-wide metrics. Monitor Changes After Launching the New Website After launch, monitoring should focus on the implementation elements that were changed and tested during migration preparation. Verify the Website's Technical Performance in the Production Environment If the way product pages are rendered has changed after migration, this group of URLs should be monitored separately. It is necessary to check whether Google continues to discover and index the expected pages, analyze their search performance, and inspect individual URLs when necessary. If internal linking has changed, the website should be crawled again in the production environment, and priority URL groups should be compared with the baseline metrics recorded before migration. Particular attention should be paid to the following metrics: Crawl depth. Number of internal links. The presence of orphan pages that have no internal links pointing to them. Routing changes should be checked using production website crawls, server logs (if available), and Google Search Console. It is necessary to identify unexpected redirects, incorrect 404 behavior, and URLs that return successful server responses while actually displaying messages indicating that content is unavailable. It is important to check the website in the production environment even when all tests in the staging environment have been completed successfully. Differences may result from CDN rules, caching, environment configuration, or the data used on the live website. Such factors can cause issues that were not present during previous testing. Analyze Performance by URL Groups After the website launch, it is important to segment not only technical issues but also its performance metrics. For example, if the website's organic traffic decreases by 3% after migration, this figure alone does not provide enough information for diagnosis. It is possible that traffic to product pages has decreased significantly, while informational content has experienced growth. Alternatively, most of the decline may be concentrated in just one language version of the website. Therefore, URL groups created during migration preparation should be used to analyze performance changes. This makes it possible to compare results by templates, page types, language versions, and other implementation characteristics. Google Search Console can be useful for this type of analysis if the URL structure makes it possible to clearly separate pages into the relevant groups. If such segmentation is not possible using standard filters, it is worth creating custom URL sets to compare the performance of different templates and migration types. The timing of changes can also provide a useful diagnostic signal, although it does not prove a cause-and-effect relationship on its own. For example, if impressions for one page type begin to decline after the new website launches, while sections with a different implementation remain relatively stable, that particular template should be investigated first. To do this, it is necessary to compare its current implementation with the baseline metrics recorded before migration and determine which specific changes may have affected its performance. Technical checks can usually begin immediately after the website launch. However, additional time is required to assess Google's response, as indexing and search ranking data accumulate gradually. The monitoring period depends on the size of the website and how frequently search engines crawl its pages. Unchanged URLs Do Not Eliminate Website Migration Risks Keeping the same URLs during migration helps eliminate one significant risk, but many SEO-critical characteristics exist at a level that is not directly related to the page address. Identifying the functions provided by the old platform in advance makes it possible to understand what needs to be tested during the website migration and monitored after launch. A migration can preserve all important URLs while simultaneously changing how search engines crawl, render, and interpret pages. Therefore, the success of a website migration should not be evaluated solely by whether its URLs and visible content remain unchanged. It is equally important to ensure that the new platform correctly reproduces all technical SEO functions, provides search engine crawlers with access to content, and preserves page behavior across different scenarios. Read this article in Ukrainian.