What clients say about Qreativa
Read client reviews of our work and collaboration on Trustpilot.
VIEW VERIFIED REVIEWSChange your domain, platform or site structure with a clear plan for organic search. We map valuable URLs, review the new site and verify the transition with your development team—not just the redirect file.
Old URLs. Clear destinations.
Map → verify → monitor
Read client reviews of our work and collaboration on Trustpilot.
VIEW VERIFIED REVIEWSDesign and platform decisions can remove content, change navigation or alter how pages render. Waiting until just before launch to involve SEO leaves less room to address those issues. We define what must survive the move, what should change and what evidence the team needs before approving the release. Temporary ranking fluctuations can still occur; no migration is risk-free.
Inventory URLs, content and search performance so important pages do not disappear simply because they are absent from the new menu.
Agree who maps, implements, tests and approves the release, including the issues that would postpone launch.
Compare the actual production output with the plan and monitor discovery, indexing and commercial traffic across old and new URLs.
Combine crawl exports, CMS records, sitemaps, Search Console, analytics and available link data. Identify valuable pages, assets and templates, then separate required changes from optional redesign decisions.
Assign each important old URL a justified outcome: retain, move, consolidate or remove. Specify direct permanent redirects to relevant final destinations and test exceptions, chains and loops.
Compare the new site with the baseline. Check valuable copy, headings, metadata, internal links, canonicals, hreflang and product information, including the HTML that search engines actually receive.
Agree the release sequence and named owners with your developers. Check redirects, indexability, server responses and tracking on the live site, with a clear process for triaging launch-blocking problems.
Follow old and new URLs through the transition. Investigate unexpected errors, missing content and losses by template or market, rather than treating every fluctuation as a reason to reverse the move.
Review products, category trees, variants, filters and locale relationships as connected systems. Preserve useful search destinations while the platform, catalogue or market structure changes.
Moving or combining domains requires URL mapping, ownership checks, working redirects and a view of both sites’ performance. We assess whether Search Console’s Change of Address tool applies.
A new platform can change metadata, variant URLs, status codes and rendering even when the visible design looks similar. We compare outputs, not the names of CMS features.
Navigation, content and page hierarchy can change without a new domain. We check whether important pages still exist, remain linked and serve the same search need.
When URLs stay the same, the focus shifts to availability, DNS, TLS, crawler access and response behaviour. A domain-move procedure is not automatically the right plan.
A priority product URL might correctly redirect to a new page that has lost its buying information, internal links or indexability. The redirect works, but the migration is not ready. Our review follows the destination through its actual content and technical response, with a documented owner for each unresolved issue.
For the operational checklist, read our SEO migration guide. If you are still choosing what to rebuild, explore our web design and development service; an ongoing audit and improvement programme belongs under technical SEO.
We use Google’s guidance for moves with URL changes and hosting changes without new URLs to distinguish the checks each project needs.
Document what changes, capture current URLs and performance, and agree who is responsible for SEO, content, development and release approval. Identify any missing access or evidence early.
Review proposed destinations and templates. Give developers implementable rules, test priority examples and edge cases, and track issues against explicit acceptance criteria.
Confirm known blockers are resolved or explicitly accepted. After deployment, test actual URLs, content, robots directives, redirects and analytics rather than relying on the staging sign-off alone.
Monitor the transition within the agreed window, investigate deviations and document remaining work. Hand over durable redirect rules, monitoring responsibilities and evidence of the checks completed.
Migration work can be scoped within Qreativa’s monthly subscription, with capacity reserved for the agreed preparation and release windows. We collaborate with your existing developers or the team building the new site. Launch attendance and monitoring duration are agreed in advance; they are not an implied round-the-clock support service.
A full website rebuild, hosting, domains, infrastructure changes, third-party tools, content production and development outside the agreed scope are separate. Access to old systems and ownership of the relevant properties are required for a complete transition plan.
Ideally before choosing the final architecture or building the new templates. That allows valuable content, URL relationships and technical requirements to influence the project. If the build is already underway, we first assess what can still change and prioritise launch-critical issues.
No. Search engines need to process the new site and rankings can fluctuate even during a carefully managed move. We reduce avoidable risk through mapping, testing and monitoring, but cannot guarantee how Google or customer demand will respond.
Preparation depends on the number of URLs, template complexity, markets, integrations and development schedule. Post-launch monitoring is a separate phase: search engines do not process every moved URL on a fixed timetable. We agree preparation milestones and the monitoring window before work starts.
Google generally recommends keeping migration redirects for at least one year. Longer retention can be appropriate when external links, bookmarks or documents still point to the old URLs. Domain and infrastructure ownership need to support that plan; redirects are not a temporary launch-day asset.
We decide whether to retain useful content, create a relevant replacement, consolidate it into a genuinely related page or remove it. A removed page with no suitable replacement should return an appropriate 404 or 410 response. Sending unrelated pages to the homepage can create a poor experience and soft 404s.
Yes. A CMS or framework change can remove important HTML, alter internal links, introduce noindex directives or return incorrect status codes without changing the address. A hosting-only move needs a different set of availability and crawler-access checks. The scope follows the actual changes.
Yes, starting with diagnosis. We compare pre- and post-launch URLs, content, redirects, indexing and measurement to separate release defects from reporting changes, demand or unrelated search shifts. Access to the old inventory and historical data improves the investigation; a recovery percentage or deadline cannot be promised in advance.
Cost follows scope: URL volume, number of templates and markets, quality of the existing map, implementation ownership and launch support required. We agree monthly capacity, deliverables and exclusions before starting. New-site development and hosting are separate unless explicitly included in the project scope.