A TYPO3 migration can go wrong in the best scenario. The new site looks good, the editors are happy, and everyone is smiling when the launch commences. Three weeks later, the organic traffic is gone, and no one can say precisely why. In most cases, the issue has nothing to do with the CMS itself but URL structures, metadata, internal linking, and overall crawlability that went south during the transition.
The checklist below should be used as a guideline for what to preserve, in what order, and how to verify everything works. It applies to migrations between TYPO3 versions, moving to TYPO3 from another CMS, or rebuilding the TYPO3 site from scratch.
Take a Baseline Before Launch
No migration project should commence without taking a baseline of the current site’s performance. It is the only reliable way to understand where the traffic came from and, more importantly, where it will go after the launch.
What to export while the site is still live:
- The crawl data for all indexable URLs with the relevant HTTP status code, title, meta description, canonical, heading structure, and hreflang tags – use Screaming Frog or similar tools for that
- Landing pages and queries from Google Search Console within the past twelve months
- The analytics data about which pages bring traffic and conversions (organic sessions, phone calls, purchases)
- Backlinks data – preferably exported from the same tool as the crawl data above
The data described above will serve two purposes: identify the pages that need special attention during and after the migration and act as the baseline for post-launch monitoring. Note that not all pages are created equal: a product page with ten backlinks and ten thousand monthly views is much more important than a blog post from 2014.
Define What’s Worth Keeping
A migration project is the best time to prune the site’s content and remove the low-value pages. It should be done deliberately and with care, not as an afterthought. All URLs found in the crawl data should be divided into three categories: kept, redirected, and removed. The last category should have redirects pointing to the most similar existing pages whenever possible. It is a mistake to point everything to the homepage: search engines will most likely penalize such redirects, and the users will never get to the page they wanted.
The goal is to keep as many URLs as possible while eliminating the noise. All pages that rank or have backlinks should be kept or redirected to high-value pages. TYPO3 has several ways to handle redirects: they can be placed in the core redirect module, with appropriate query string handling and expiry rules, or in the web server config for bigger projects. The decision should be made based on the technical capabilities and the resources of the team handling the migration. A redirect module in TYPO3 is easier to manage but cannot handle thousands of redirects efficiently.
Several notes about redirect management:
- Always use permanent (301) redirects for entries that have been moved to another location.
- Avoid redirect chains if possible: if URL A points to B, and B points to C, it is better to redirect A to C directly.
- Make sure redirects work correctly with trailing slashes, uppercase letters, and subdomains (www vs. non-www).
- Remember that old TYPO3 sites often used query strings in their URLs: index.php?id=123 may have real content and external links.
Keep On-Page Signals Consistent
The search engines will evaluate the new page based on its content. Even if the redirect is set up correctly, large-scale changes to the title, headings, body text, and internal links can cause a drop in rankings. It is essential to keep the on-page content similar to the old page for the critical URLs identified in the baseline crawl.
Compare the following elements for every URL in the crawl data:
- Title and description tags – usually available in the page properties
- Page headings and structure – TYPO3 pages typically have one H1 tag at the top
- Canonical tags – should point to the preferred version of the page; avoid pointing to the staging version of the site
- Structured data – if the old pages had it for products, events, organizations, and FAQs
- Image Alt text and filenames – images are often discovered through search queries
It is not necessary to keep the content exactly as it was on the old page. It may be possible to improve the old content during the migration. However, changing the content management system, the template design, and the actual content at the same time is too much to attribute the ranking drops afterward.
Keep hreflang Tags and Pay Attention to Cookies
TYPO3 sites are often multilingual, and such sites require extra care during migrations. Every language version of the page must have correct hreflang tags with language and region subtags pointing to other variations of the page. The most common mistake is to forget that German-speaking European countries have different language subtags: de-DE (Germany), de-AT (Austria), de-CH (Switzerland). The same nuance applies to other languages and regions.
There are two additional changes that are easy to overlook in a TYPO3 migration project: Impressum (legal information page) and cookie consent. Both elements are often blocked by default in TYPO3, so it is necessary to make sure they are available on all pages in TYPO3 after the launch. With the implementation of the new privacy regulation (DSGVO), analytics scripts without user consent may be blocked entirely. At the same time, incorrect cookie consent banners can skew the traffic data heavily, especially right after the launch.
Have a Staging Environment, and Keep It Private
A staging environment is necessary to test the migration before the launch. It should be secured in such a way that search engines cannot access it; using the HTTP auth is one way to do that. It is easy to add a noindex directive to all pages accidentally, which can lead to a decrease in traffic after the launch. Having a noindex on a live environment should always be double-checked; ideally, it should be on the go-live checklist. It is also a good idea to have a technical review of the staging environment before launch to ensure nothing was missed.
A TYPO3 migration may require external expertise, especially if the team has little experience with the CMS or if the technical task is large. A company offering Softwareentwicklung Outsourcing can handle small adjustments to the existing TYPO3 site, but the technical requirements for a larger project should be defined clearly from the beginning. Someone without a detailed understanding of the redirect structure will not be able to secure it properly.
It is worth running some basic checks on the staging environment before launch and comparing the results with the baseline data described above. The following tests should be performed with a crawler:
- Does the new TYPO3 site have all the necessary pages?
- Are the page titles, canonical tags, and other elements similar to the baseline?
- Does the internal linking still point to the same pages?
- Does every URL in the priority list resolve correctly?
- Does the redirect structure work as intended? A crawler can test it by following all the old URLs in the list one after another in list mode and checking if each of them returns a 200 HTTP status code
Testing the performance is also a good idea here: the TYPO3 template should not be significantly heavier than the old one. It is possible to use Core Web Vitals to test the most critical templates right before the launch.
Define When and Who Launches
It is best to avoid peak seasons for such projects. A slow week is much better for everyone involved than a busy one, and the lower traffic will help see the traffic changes after the launch more precisely. It is probably not a good idea to launch on a Friday and leave everyone to fend for themselves on the weekend.
The migration launch should also have a responsible person or team. Developers, the team handling the redirect table, and someone with SEO expertise should be available for the launch day. Some companies prefer local outsourcing to handle the launch in person. For example, if there is a Softwareentwicklung in Hamburg and an urgent need for developers to look over the TYPO3 project during the most critical time, the local team will always be a safer option than distant colleagues. It is more important to choose the right person for the task rather than focus on where they are located: a competent professional will understand what to do during the TYPO3 launch.
Final Checks, Launch, and the Following Weeks
Several standard tasks should be performed when the TYPO3 migration goes live:
- The staging restrictions (if any) are removed, and the noindex directives are taken off.
- The robots.txt file is checked to ensure that search crawlers are allowed to access the site.
- Redirects are enabled, and a few critical URLs are double-checked.
- The new XML sitemap is submitted to Google Search Console; the one generated by TYPO3 SEO extension should work fine.
- The Change of Address tool is used in Google Search Console if the domain has changed; the redirects for the old domain should be in place permanently.
- Analytics and cookie consent banners are checked to ensure they work correctly.
Pages and Crawl Stats reports in Google Search Console should be monitored for a sudden rise in 404 errors, server-side errors, or pages dropped by Google. Another full crawl of the site’s indexable URLs should be done a few days after the launch, as some issues may only reveal themselves in a production environment. The number of organic impressions for the URLs found in Google Search Console should also be compared to the baseline figures every week after the launch.
Large-scale migrations always affect the site’s position in the search results in some way, but it is hard to predict how significant the changes will be for specific URLs. In most cases, ranking changes are related to redirects, canonicalization, and on-page content changes, so those should be reviewed regularly. A small drop in rankings in the first few days is normal for pages that have been crawled for the first time since the launch. However, a steady decline on particular URLs or an increase in traffic to low-quality pages after the launch may indicate an issue.
Redirects should be kept as long as the old URLs have traffic or backlinks. Therefore, a small technical debt is acceptable if it makes the migration easier. Removing old redirects after a few months to clean up the table is a typical mistake.
A Practical First Step
Before anything else, take your fifty most important organic landing pages from Google Analytics and crawl each of them to find out what happens to these URLs after the migration. Ideally, a redirect should be placed behind every single URL pointing to a relevant page, and the on-page content should be compared. If you cannot trace fifty URLs, your migration plan is not ready yet. The technical part of it can be handled by Softwareentwicklung in Berlin or another competent team, but this simple check will help prioritize the work.
