SEO
How to migrate a Bolt.new service website without losing enquiries
Move a Bolt.new business site safely: inventory pages, export data, protect URLs, retest bookings and plan rollback before DNS cutover.
Start with a map of what is live, not the new design
A Bolt.new website may be more than a collection of pages. It can include a database, authentication, lead capture, a custom customer portal and integrations. A new visual design will not preserve those behaviors automatically. Before you move anything, create a dependency inventory and decide which features are genuinely being replaced.
Record the existing domain, all public URLs, redirects, forms, data tables, email providers, calendar links, payment paths, environment variables and scheduled tasks. Mark the owner for each item. Keep secrets out of the migration document; record where they are stored, not their values.
Separate four kinds of assets
Search assets: important pages, titles, headings, internal links, structured data if any, image descriptions and historical URL redirects. Customer assets: contacts, approved notes, lawful consents and legitimate retention requirements. Operational assets: booking availability, staff calendars, active appointments, unfulfilled payments and confirmation templates. Technical assets: database rules, source code, domains, analytics configurations and third-party dependencies.
A website move can transfer the first category without replacing the others. That may be the safest first release.
Make a URL map before deleting old pages
Avoid treating every removed URL as a homepage redirect. That hides content loss and frustrates visitors. Preserve existing search intent, not merely the domain name.
| Old asset | Proposed action | Verification |
|---|---|---|
| Main service page with inbound links | Keep its slug where practical or use a permanent redirect | Request returns the intended new page |
| Location page with original proof | Recreate genuinely useful geographic content | Title, copy and contact route match the region |
| Old booking URL | Map to real working booking or explanatory request flow | No broken deep links from emails |
| Thin duplicate location page | Consolidate into a useful primary page | Single destination, no redirect chains |
| Expired one-time promotion | Retire or redirect only when the destination makes sense | No misleading offer remains |
Validate customer workflow on real scenarios
Test an ordinary appointment
Select the service, inspect the duration and availability, complete a test booking and confirm which client record was created. Check that the notification tells the person what happens next. Then reschedule or cancel and inspect the calendar state, not just the UI confirmation.
Test a request that is not a reservation
A project enquiry and a confirmed appointment are different contracts. For a custom-estimate business, do not show a fake "booked" status when the request still requires review. Use a clear request received message and defined response owner.
Test failure and privacy conditions
Try a date in another time zone, a double-click submission, a missing required field, an inaccessible staff member and an offline email service. Confirm the legal basis and security of the customer data being moved. Data exported from one application is not necessarily suitable to import wholesale into another.
Build a phased launch sequence
Seven days before: freeze URL inventory, verify access to both domain accounts and copy recent metrics for comparison. Two days before: place test contact requests, schedule and cancel sample bookings, and verify email delivery. Cutover day: publish, update DNS using the provider's instructions, inspect HTTPS, and sample old redirect destinations. First week after: monitor errors, dropped leads, unavailable slots and search indexing signals. Maintain a rollback path where feasible.
Do not promise uninterrupted analytics attribution across a changed stack. Document the measurement changes explicitly.
A practical acceptance scorecard
Next step: Review the OneStudio workflow and contact the team with your current URL map. Test the new operational flow before replacing the old site.
- Every high-value URL resolves to the correct page or a sensible permanent redirect.
- The contact and booking actions work from an ordinary phone browser.
- Staff cannot accidentally expose or double-book unavailable resources.
- Current appointments have a named system of record.
- Customer data was moved only with appropriate access and retention controls.
- The owner can edit content, handle cancellations and find new enquiries.