Technical SEO
Website migration
I build a full picture of the current site before the migration: a list of URLs with their statuses, the key page types and templates, and the indexing elements to carry over. I create a baseline for “before/after” comparisons and set out the requirements and risks in the areas of URLs, pagination, parameters, canonicals, meta robots, headers, linking and sitemaps.
About the service
Inventory and analysis of URLs, templates and indexing for a website migration
About the website migration service
A few service details- List of site URLs and statuses
- Identification of page types
- A “before” baseline for comparisons
- Analysis of URL structure and parameters
- Verification of canonicals and meta robots
- Assessment of linking and sitemaps
Work process
The SEO migration process: from planning to implementation
I start an SEO migration by defining the type and scope of the changes and collecting data about the current site. On that basis I plan the URL mapping, the redirects and the scope of testing, matching them to the technical possibilities and the implementation schedule.
- 01/ 03
Diagnosis and migration scope
I define the type of migration (e.g. domain, URLs, CMS, redesign), analyse the scale of the changes and establish whether the URLs will change and what the consequences for visibility will be.
- 02/ 03
Access and technical preparation
I collect the necessary data (traffic, indexing, URL list) and verify access to the server, the CMS and the test environment, so that the mapping and tests can be prepared.
- 03/ 03
Migration plan and implementation
I prepare the URL map and the list of redirects, define the “freeze” rules and support the implementation, minimising the risk of errors and traffic losses.
Types of SEO migration: key aspects
The type of SEO migration defines what exactly is changing on the site and which actions need to be planned to limit the risk of losing visibility. At this stage it is established whether the migration concerns the domain, the protocol, the URL structure, the platform/CMS, a redesign, content changes, language versions, or merging/splitting sites. This choice directly affects the work plan, the redirects needed and the scope and method of testing. The more areas change in parallel, the more decisions and checks will be needed in the next stages.
A key point is the decision on whether we change the URLs in the migration or keep the existing URL structure. Changing the URLs determines the size of the mapping, the list of redirects and the risk of 404 errors, so it requires clear decisions before preparations begin. In parallel, it has to be settled how to handle content that is removed or merged: whether it should be redirected to the closest page by topic, kept as an archive, or return 404/410. These decisions translate into the quality of the index and the consistency of SEO signals after implementation.
The scope of work in a migration is also affected by the size and complexity of the site, including the number of URLs, page types, filters/parameters and integrations. In practice, this translates into the time needed for mapping, the number of exceptions and whether the tests will cover the full list of URLs or a representative sample. If a redesign or major changes to the content and information structure are happening in parallel, the risk and the scope of QA grow, and the mapping requires more decisions. A lack of development resources, CMS limitations or no control over the server configuration can limit the ability to fully implement the recommendations, including redirects and robots/sitemap elements.
- Domain, protocol, URL structure, platform/CMS, redesign
- Content changes and decisions on merging/removing pages
- Language and regional versions and the relationships between them
- Merging or splitting sites and the consequences for mapping and testing
Kick-off and technical arrangements: the first step in a migration
The kick-off and technical arrangements are the stage at which information about the planned changes and the implementation date is collected and the way of working together throughout the migration is agreed. During this meeting/stage, the environments the team will work on are specified, including production and test, along with the rules for verifying implementations. The responsibilities of those implementing and those approving the changes are also established, as is the way of communicating. These arrangements give the process order and limit the risk of discrepancies in the next steps, e.g. in URL mapping and testing.
At the start, access and input data are needed in order to prepare reliable analyses and checks. What is required is access to traffic and indexing data, the URL list and the DNS/server/CMS configuration, as well as the ability to check implementations in the test environment. Access to the full version of the site before publication — with the URL map, templates, headings, meta, linking and robots/sitemap — makes QA easier and limits the risk of losing visibility. Without these elements, some of the checks have to be moved to after publication, which increases the cost of fixes and the risk of errors.
The kick-off is also where the decision is made on whether we change the URLs, because this determines the size of the mapping and the list of redirects. It is also worth agreeing on the implementation window and the change “freeze” period, i.e. limiting content/URL changes before and after implementation. This reduces the risk of the mapping drifting out of sync and makes it easier to diagnose problems on publication day and during stabilisation after the migration.
- Collecting information about the planned changes and the implementation date
- Establishing the environments (production/test) and the method of approval and communication
- Access required: traffic data and indexing data, URL list, DNS/server/CMS, verification of implementations in test
- The decision on whether we change the URLs, and agreeing the rules for the change “freeze”
Access and input data: what is essential?
Access and input data are essential for preparing the migration on the basis of real data about the site and for verifying that implementations are correct. In practice, the work relies on traffic and indexing information, a complete list of URLs and the settings that affect how the domain and server work. This data makes it possible to build a point of reference (baseline) and to plan the mapping and redirects in a way that is consistent with the actual structure of the site. Without it, some decisions and checks cannot be carried out unambiguously.
Information about the DNS/server/CMS configuration is also required, because it determines whether redirects and indexing-related settings can be implemented. The ability to verify implementations in the test environment is key, to confirm that the changes match what was agreed before publication. Based on the data collected, operational materials can be prepared, such as the URL map (old → new) and the list of redirects, and the tests can be planned. This also makes quick diagnosis easier when there are discrepancies between the plan and what has actually been implemented.
- Access to traffic and indexing data
- The site’s URL list as the basis for the inventory and mapping
- Information about the DNS/server/CMS configuration
- The ability to verify implementations in the test environment
A test environment for QA: minimising risk
A test environment for QA minimises risk because it makes it possible to test the full version of the site before publication. The condition for effective QA is access to a version that reflects the planned changes to the structure and SEO elements, not just fragments or individual templates. In test, it is possible to check that the URL map is followed, how the templates work, and the elements that affect indexing and the transfer of SEO signals. As a result, problems can be caught and passed on for fixing before launch.
QA verifies, among other things, redirects, HTTP statuses, indexing, canonicalisation, metadata, internal linking and the robots and sitemap configuration, as well as the absence of technical pages from indexing. The scope of testing is set depending on the size and complexity of the site, choosing either tests of the full URL list or a representative sample. The outcome of the work is a report of errors to fix before launch, with priorities and a recommendation for the fixes (what to fix and where). A go-live and QA checklist is used to plan and carry out the checks; it organises the verification before and on the day of implementation.
- Tests of the full version of the site before publication (URLs, templates, elements in the page head)
- Checking robots/sitemap and the indexing and canonicalisation elements
- Verification of redirects, HTTP statuses and 4xx/5xx risks
- A report of errors to fix before launch, and a go-live and QA checklist
Inventory and baseline: the foundation of a migration
The inventory and point of reference (baseline) is the stage at which I build a full picture of the current site, so that the state after the migration can be assessed reliably. In practice, this covers collecting the list of current URLs and their statuses, and identifying the key page types and templates. In parallel I organise the indexing-related elements that may need to be carried over or recreated after implementation. The data collected is the point of reference for verifying changes and detecting discrepancies after publication.
This stage also helps to establish which areas of the site are critical in the migration and need particular attention in the next steps. Thanks to the inventory, decisions on moving, merging or removing pages can be tied consistently to the mapping and testing plan. The baseline makes it easier to compare the “before” and “after” states, including checking whether the key pages have remained available and are served correctly. It is also the basis for prioritising the work when the site is extensive and includes many page types.
- Collecting the list of current URLs and their statuses
- Identifying the key pages and template types
- A list of indexing-related elements to preserve in the new version
- Preparing a baseline for the post-migration assessment
Analysis of URLs, templates and indexing: the key elements
The analysis of URLs, templates and indexing means checking whether the key SEO signals can be carried over to the new version of the site without losing consistency. I verify the URL structure and the elements that often cause problems in migrations, such as pagination and parameters. I also check the canonical URL settings, meta robots and headers, because they affect indexing and content duplication. The aim is to set out the requirements and risks that need to be taken into account in the mapping, redirects and QA.
The analysis also covers internal linking and sitemaps, because they must support the target URLs and not carry over accidental URL versions. I assess whether the current logic of URLs and indexing signals can be recreated given the planned changes to the site. The results of the analysis are the basis for deciding what should be kept and what should be changed in the new templates and configuration. This makes it possible to prepare the implementation requirements in a way that is consistent with the actual structure of the site.
- Checking the URL structure, pagination and parameters
- Verification of canonicals, meta robots and headers with the transfer in mind
- Assessment of internal linking and sitemaps in the context of the target URLs
- Identification of indexing elements that need to be preserved in the new version
Testimonials
What clients and the industry say
Feedback from clients and industry people I have worked with on SEO projects.
I had the chance to work with Kuba at Kulturalnie o SEO, an event I organise. Kuba did a great job as a speaker and received high marks from the audience. He showed professionalism and broad knowledge. In other projects at Vestigio, Kuba shows enormous commitment, a willingness to explore and implement new ideas, and excellent organisation of his work.
01 / 08
You talk to me, not a salesperson
Tell me what you want to achieve. I’ll reply personally
I work as a freelancer: the same person reads your message, prepares the quote and then runs the project. No sales team in between.