A redesigned homepage can look excellent while an important service URL stops working or a contact form sends requests to the wrong inbox. Protecting your SEO investment means checking more than the new appearance.
This checklist is for the business owner approving the project and the people responsible for content, development, and SEO. It focuses on continuity during a redesign, whether you keep the same platform or move between Joomla and WordPress.
Start with a preservation list
Before anyone deletes pages or changes navigation, inventory the current public URLs. Include service pages, useful articles, location information, important downloads, and other destinations customers may already use.
Review available search, analytics, inquiry, and backlink evidence alongside business knowledge. A page with little measured traffic may still answer an important customer question or serve an existing customer. Missing analytics is not evidence that a page has no value.
For each important page, record:
- The current public URL and the customer need it serves.
- The services, factual information, images, or proof worth retaining.
- Available visibility, traffic, inquiry, or link evidence, with its limitations.
- The proposed action: keep, improve, merge, move, or retire.
- The person responsible for approving the decision.
This is the business's preservation list, not a requirement to keep every sentence. Improve outdated or weak material while protecting the useful information and pathways customers already depend on.
Decide whether each URL needs to change
A visual redesign does not automatically require new page addresses. Where an existing URL still describes the page accurately, keeping it can reduce migration complexity.
When URLs do change, create an explicit old-to-new mapping. Google's site-move guidance recommends preparing the new site, mapping changed URLs, implementing redirects, and monitoring the transition. It also cautions that search fluctuations can occur while changes are processed.
Illustrative mapping decision: an old kitchen-remodeling page has a clearer replacement covering the same service. Map the old page directly to that replacement. If two overlapping pages are combined, preserve their useful material in a relevant destination. Do not send unrelated retired URLs to the homepage merely to avoid an error message.
Ask the developer to document pages retired without a relevant replacement, rather than silently redirecting everything. The mapping should explain the customer destination, not just list a technical rule.
Check platform details that can change public addresses
On Joomla
Inspect article, category, and menu aliases, the menu structure, and the routing configuration in use on the actual site. Joomla's alias documentation explains that aliases help form search-friendly URLs and are distinct from the displayed title.
Do not assume that preserving an article's alias alone preserves every public route. Ask the implementer to compare the complete old and new URLs after menu or category changes. Joomla versions and extensions can differ, so a before-and-after URL test is more useful than a generic promise that the migration tool handles everything.
On WordPress
Review the permalink structure and individual page or post slugs. WordPress documents how permalink settings form public URLs. A new theme should not be treated as a reason to reset those choices without a migration plan.
Also ask who owns SEO metadata, forms, redirects, and any custom content types in the new build. If a plugin or theme changes, verify the resulting public output. The presence of an SEO plugin does not demonstrate that the old settings and useful content survived.
Test the new site before approving launch
Review representative pages from every important template, including long service pages and forms. Use the preservation list to prevent the home page from receiving all the attention.
- Content: Are core services, contact details, useful images, and important qualifications still accurate and visible?
- Navigation: Can customers reach priority services without relying on site search?
- Page signals: Are titles, headings, canonical destinations, and relevant structured data accurate?
- Mobile use: Are text, controls, menus, and forms usable on a real phone?
- Inquiry delivery: Does a test request reach the intended business recipient, and does the visitor receive the expected confirmation?
- Measurement: Are the intended analytics events recorded once, with test activity identified?
- Assets and downloads: Do essential images, documents, and linked resources still load?
Keep staging protected appropriately. Before launch, document which development-only access restrictions or indexing directives must change for the public site, and who will verify that change. Do not confuse removing an accidental launch block with removing security protections generally.
Verify redirects by their destinations
A redirect should carry the visitor to the intended replacement, not just make the browser display something. Test important old URLs directly, including ones found in search, directories, emails, or printed materials.
Google's redirect guidance distinguishes permanent from temporary moves. For a permanent URL change, have the implementer choose the appropriate permanent redirect and verify it works without a loop or an unnecessary chain.
Update internal links to point to the final destinations rather than depending on redirects for routine navigation. Check sitemap and canonical references for old or staging addresses. Agree who will maintain redirect rules after the design project ends.
Use a launch decision, not just a launch date
Assign one person to make the go/no-go decision from completed checks. Important blockers include broken inquiry delivery, missing core service pages, unresolved URL mappings, or an unintended restriction on the production site.
Keep a tested backup and a practical recovery plan. Identify who can restore the site, what would trigger that decision, and how new inquiries or content created after launch would be protected. An old backup is not a complete rollback plan if restoring it would erase recent business data.
If the project also changes hosting or DNS, include those responsibilities and any email dependencies in the launch plan. A design approval should not leave the team guessing who handles an infrastructure problem.
Agree on post-launch checks before signing off
Inspect the actual public website immediately after release, even if staging passed. Test priority URLs, redirects, navigation, telephone links, forms, and tracking again. Record the launch time and any fixes.
Then review indexing information, search performance, inquiry counts, and customer feedback over appropriate follow-up periods. Compare like-for-like data and separate measurement changes from customer changes. A tracking tag that stopped firing can produce a dramatic chart without proving that visits vanished.
Set a handover that names outstanding tasks, monitoring responsibility, and escalation contacts. Ongoing SEO should use that evidence to choose improvements rather than treating the redesign as a finished marketing strategy.
Protect the useful work while improving the website
Guardian's SEO services consider technical access, service content, and inquiry paths together. When comparing project proposals, use our proposal checklist to make implementation and reporting responsibilities clear.
Discuss your Joomla or WordPress redesign with Guardian Solutions before launch. Bring the current website, intended platform or design changes, and the pages or services your business most needs to protect.