The most expensive TYPO3 to WordPress migration problems are the ones nobody notices until after the domain switch: URL slugs that were generated from titles instead of the original TYPO3 segments, FAL file references that resolved on the staging server but broke in production, tx_news records that were counted as migrated but never actually imported from the extension table. This checklist exists to catch those problems on staging, before they go live.
How to Use This Checklist
Work through every item on a staging environment that has the WordPress site at the final pre-launch state. Do not skip to the domain switch until every item is confirmed. The checks are ordered by impact: content completeness first, then URL and SEO integrity, then technical health, then go-live. An issue discovered in check 3 is significantly cheaper to fix than one discovered in check 13.
Phase 1: Content Completeness (5 Checks)
1. Page count matches the TYPO3 page tree
Count the published pages in the TYPO3 pages table: SELECT COUNT(*) FROM pages WHERE deleted=0 AND hidden=0 AND doktype IN (1,4) (doktype 1 = standard page, doktype 4 = shortcut). Compare this to the published page count in the WordPress admin. A discrepancy of any size means pages were silently missed. Check the page tree hierarchy in WordPress to verify that parent-child relationships match the original TYPO3 structure.
2. Content element count per page
For a representative sample of pages, compare the number of content elements in TYPO3’s tt_content table to the number of Gutenberg blocks in the corresponding WordPress post. Run: SELECT pid, COUNT(*) as elements FROM tt_content WHERE deleted=0 AND hidden=0 GROUP BY pid on the TYPO3 database. Check that complex pages with multiple content columns have all elements present in the correct order. Content elements in non-default columns (colPos values other than 0) are commonly missed.
3. tx_news records migrated completely
Count the records in tx_news_domain_model_news where deleted=0 in the TYPO3 database. Compare this to the WordPress post count. Open several news records and verify that the publication date, author attribution, category assignment, and body text are correct. Check that attached images (linked via FAL) appear as featured images on the corresponding WordPress posts. A common failure: the tx_news table was not read at all because the migration only processed tt_content and pages.
4. FAL file references resolve correctly
Click every image in the migrated site and verify that it loads. Open the WordPress Media Library and check the total file count against the count in sys_file in the TYPO3 database. Open several images in the Media Library and verify that the alt text field was populated from sys_file_reference.alternative or sys_file.alternative rather than left blank. FAL file references store alt text at the reference level (per content element) rather than the file level, and this per-reference value is commonly lost when only sys_file is read.
5. Frontend user accounts and form submissions present
Check the frontend user count in fe_users (where deleted=0) against the WordPress user count. For sites using Powermail, EXT:form, or similar form extensions, verify that submission history was exported and is accessible. Check that user role assignments match the intended WordPress role mapping from TYPO3 frontend user groups.
Phase 2: URLs and SEO Integrity (5 Checks)
6. URL slugs match original TYPO3 segments
This is the single most important check in the entire list. Take twenty page URLs from the original TYPO3 site and verify that each one resolves correctly on the WordPress staging environment. The TYPO3 URL segment for each page is stored in the slug field of the pages table (TYPO3 v9+) or was managed by the RealURL extension in older versions. A migration that generated WordPress slugs from page titles may have matching results for some pages and different slugs for others. Every non-matching slug needs a 301 redirect.
7. 301 redirects are in place for all URL changes
For every URL that changed between the TYPO3 site and the WordPress site, a 301 redirect must exist. Test the original TYPO3 URL on the WordPress staging environment and confirm it returns a 301 with the Location header pointing to the correct WordPress URL. A 404 response means the redirect is missing. Use a tool like Screaming Frog to crawl both the original URL list and the WordPress staging environment, comparing response codes.
8. SEO metadata transferred from TYPO3 page properties
TYPO3 stores SEO titles, meta descriptions, and Open Graph fields in the pages table columns (seo_title, description, og_title, og_description) when using EXT:seo, or in custom page properties fields in older installations. Open five representative pages in WordPress and check that the Yoast SEO title and meta description fields are populated with the values from TYPO3. Auto-generated titles and empty meta descriptions indicate that the page properties were not read during migration.
9. Multilingual content correctly mapped
If the TYPO3 site had multiple languages, verify that the translated content is present in WordPress and that the language switcher (WPML or Polylang) correctly links page translations to each other. TYPO3 stores translated content as additional pages rows with a sys_language_uid field. The original language content and all translations must be imported as separate WordPress posts linked by the translation plugin.
10. Canonical tags are correct
Check the canonical tag on five representative pages using browser developer tools. The canonical should point to the final clean URL on the new WordPress site with the correct domain, not to the old TYPO3 URL, not to a staging domain, and not to a URL with the wrong protocol. Incorrect canonical tags cause ranking signals to be distributed incorrectly and can persist for months without triggering visible symptoms.
Phase 3: Technical Health (3 Checks)
11. No 404 errors from previously indexed URLs
If the TYPO3 site was live and indexed, check Google Search Console for any 404 errors after the domain switch. Any previously indexed URL that now returns a 404 is a ranking signal being discarded. These should all be 301 redirected to the nearest equivalent page on the new WordPress site. Address these within the first two weeks after launch before Google processes the migration at scale.
12. Page speed comparable to or better than the original site
Run the homepage and two inner pages through Google PageSpeed Insights. Compare the scores to the original TYPO3 site. A significant regression usually indicates that images were not optimized during import, that a heavyweight WordPress theme was applied, or that caching is not configured. Address speed issues before the domain switch since page speed is a ranking factor and a regression immediately post-migration can compound the ranking impact.
13. Forms are functional with correct notification email routing
Submit a test entry through every contact form and registration form on the site. Verify that the submission appears in the WordPress admin (or the form plugin’s inbox), that the confirmation email is sent from the correct address, and that notification emails arrive at the right recipient. TYPO3 form extensions and WordPress form plugins have different email configuration systems and the settings must be explicitly reconfigured on the new installation.
Phase 4: Go-Live Verification (2 Checks)
14. 301 redirects survive the domain switch
After the live domain is pointed at the WordPress installation, re-run the URL tests from check 7. Redirects that were configured with the staging domain hardcoded may break after the domain switch. Verify that every redirect uses a relative path or the correct live domain in the Location header, not the staging URL.
15. Google Search Console accepts the new property
Verify the new WordPress domain in Google Search Console, submit the XML sitemap generated by Yoast SEO or a sitemap plugin, and monitor crawl errors over the first two weeks post-launch. A TYPO3 site may have had a different sitemap structure that Google was familiar with. Submitting the new sitemap immediately after launch accelerates Google’s processing of the migration and reduces the window during which old URLs compete with new ones in the index.
Why Most TYPO3 Migrations Fail These Checks
Most failed checks on this list have the same root cause: the migration did not read the TYPO3 database directly. A migration that scraped rendered HTML missed all structured data in the database. A migration that used a generic tool missed the tx_news extension table, the FAL file reference metadata, and the URL slug field in pages. A migration that was done by a developer unfamiliar with TYPO3’s schema did not know which tables to read.
gConverter migrates TYPO3 sites by reading every relevant table in the source database directly. Every check on this list is covered before the staging environment is presented for client review. The domain switch does not happen until every item is confirmed.
How gConverter Handles Your Data
A TYPO3 database contains personal data subject to GDPR. Before any access, gConverter signs a Data Processing Agreement. Credentials are stored in AES-256 encrypted vaults, transferred over TLS 1.3, and deleted within 24 hours of project completion. All client data is permanently deleted within 30 days with written confirmation. We are US-registered with full EU GDPR compliance and a 72-hour breach notification commitment.
Read the GDPR and data protection documentation →
What Clients Say
Went FAR above and beyond to help us work through this project. We are thrilled with the final result and they were professional, great to work with, and responsive every step of the way. Would highly recommend.
Anna P., Wilmington NC – Customer Lobby, January 2026
Very few conversion issues on the first pass, and they cleaned it right. Very Impressive.
Stacy C., Katy TX – Customer Lobby, November 2025
The Bottom Line
A TYPO3 to WordPress migration that passes all 15 checks on this list is a migration with no silent content loss, no broken URLs, no missing SEO signals, and no surprise 404 errors in the first month of traffic. The work to get there happens before the domain switch, on the staging environment, with real source database comparisons. Not after launch, when the damage is already visible in Search Console.