Launch Checklist

Bringing your domain to Ploy is a big moment. This checklist covers the two things that matter most: protecting your search rankings and keeping your site operational throughout the transition.

SEO

A domain migration done carelessly can lose months of accumulated search equity. Follow these steps and Google will treat the move as a seamless continuation — not a new site.

Before you cut over

  • Crawl your existing site. Export a full list of indexed URLs from Google Search Console before making any DNS changes. This becomes your redirect map.
  • Preserve your URL structure. Where possible, keep paths identical on the Ploy site. Every URL you change requires a redirect — and redirects dilute link equity slightly. Identical paths pass it cleanly.
  • Carry over your meta. Verify that every page in Ploy has the same title tag, meta description, and canonical URL as the original. Ploy's Layout component handles canonicals automatically once your domain is set as the default.
  • Audit your structured data. If your old site had JSON-LD (Article, Product, FAQ, etc.), confirm equivalent markup is present in the Ploy pages before launch.
  • Check your robots.txt. Make sure Disallow: / is not present — it's a common staging leftover that will block all crawlers on launch day.
  • Know your canonical domain. Is your site currently served on the apex domain (example.com) or the www subdomain (www.example.com)? Whichever one Google has indexed is your canonical — the other should redirect to it. If you're currently on www, note why: some hosting providers and CDNs require it for CNAME-based routing. Ploy supports both. When you set your default domain in Ploy, match your existing canonical to avoid a signal split during the migration.
  • Audit your robots.txt and sitemap. Open yourdomain.com/robots.txt and check what's allowed, what's blocked, and where the sitemap is pointed. Then open the sitemap itself — note what it's called (sitemap.xml, sitemap_index.xml, or something custom), confirm all URLs inside return 200, and cross-reference against GSC's Coverage report to identify any URLs that are listed but not indexed. Fix broken or excluded URLs before migration — don't carry the problem into Ploy.
  • Establish a traffic baseline. Before touching anything, screenshot or export your current performance data from Google Analytics and Google Search Console. Record your top pages by traffic, your average position for key queries, and your weekly click and impression trends. If you don't have GA or GSC set up yet, do it now — you need this baseline to know whether the migration helped, hurt, or did nothing to your organic performance. Connect both to Ploy's Analytics integration so data flows forward from day one.

At cutover

  • Set up 301 redirects for any changed URLs. Use Ploy's routing rules to map old paths to new ones. 301s signal a permanent move and pass full link equity to the destination.
  • Set your canonical domain. In Ploy's domain settings, elect one domain (e.g. www or bare domain) as canonical. Ploy will 308-redirect the other variant automatically — no duplicate-content risk.
  • Update your sitemap. Ploy generates /sitemap-index.xml automatically from all prerendered pages. Confirm it reflects your final URL set before going live.

After cutover

  • Submit your sitemap to Google Search Console. Go to GSC → Sitemaps, paste https://yourdomain.com/sitemap-index.xml, and submit. GSC will begin recrawling within hours.
  • Request indexing on key pages. Use GSC's URL Inspection tool on your homepage, highest-traffic pages, and any pages with changed URLs. Click "Request Indexing" to prioritise them.
  • Monitor GSC for 2–4 weeks. Watch Coverage and Performance reports for unexpected drops in impressions, clicks, or crawl errors. A short-term dip (1–2 weeks) is normal — a sustained drop signals something is misconfigured.
  • Verify backlinks still resolve. Check your top-linked pages in GSC or a backlink tool and confirm the redirects are working. Broken inbound links bleed authority.

Operations

The goal is zero downtime and zero surprises. The steps below give you a controlled, reversible cutover so your site stays live for visitors at every stage.

Before you cut over

  • Do you need a CMS for blog or editorial content? If you publish blog posts, changelogs, or other regularly updated content, decide how that content will be managed on Ploy. If your blog lives on the same domain you're migrating (e.g. example.com/blog), note which CMS or platform currently powers it (WordPress, Contentful, Ghost, Webflow, etc.). Ploy supports markdown-based content collections natively and can also proxy a subdirectory to an existing CMS over a routing rule — so your blog can stay on its current platform while the rest of the site moves to Ploy.
  • Do you conduct e-commerce on this domain? If your site processes purchases — product pages, a cart, checkout — note which platform handles it (Shopify, WooCommerce, Stripe, etc.) and whether it's embedded on the domain or hosted on a subdomain. Ploy is optimised for marketing sites; transactional flows typically live on a separate subdomain or third-party-hosted storefront. We can proxy /shop or /checkout paths to your existing commerce platform so customers see a seamless experience under one domain.
  • Do you host a dynamic or authenticated web app on this domain? If part of the domain serves a database-backed application — a customer portal, dashboard, or any route that requires a login — that cannot move to Ploy directly. Tell us where the app is currently hosted (Vercel, Render, AWS, Heroku, etc.) and which paths it occupies. Ploy's routing rules and fallback proxy can forward those paths to your existing app server while Ploy serves everything else, keeping the domain unified for visitors.
  • Do you need intake or sign-up forms? If your site captures leads, waitlist signups, contact requests, or any other form submissions, Ploy handles these natively — submissions are captured in the dashboard and can trigger webhooks to your CRM or marketing stack. If you're currently using a form vendor (Typeform, HubSpot Forms, Marketo, Gravity Forms, etc.), let us know — we can either replace it with a native Ploy form or embed your existing form within the migrated pages so nothing breaks on cutover.
  • Lower your DNS TTL. 24–48 hours before switching, reduce your domain's TTL to 300 seconds (5 minutes). This means propagation after cutover will be near-instant rather than hours-long.
  • Set up a fallback proxy. Ploy can proxy any unmatched routes to your existing host during the transition. Configure this before the DNS switch so visitors landing on pages not yet migrated are served seamlessly from the old host. See the Fallback Origins guide for your current provider.
  • Smoke-test in Ploy first. Use the Ploy preview URL (your *.ploy.build domain) to walk through every critical page, form, and flow before any DNS change touches production.
  • Document your rollback plan. Know exactly what DNS records to restore if you need to revert. Keep the old host's configuration live and ready for at least 72 hours post-cutover.

At cutover

  • Add your domain in Ploy and get your DNS records. Ploy will give you the exact records to add. See the Custom Domains guide for step-by-step instructions.
  • Update DNS at your registrar. Point your A / CNAME records to Ploy's edge. With a 5-minute TTL, most visitors will see the new site within minutes.
  • Verify SSL is active. After DNS propagates, confirm the padlock is showing and there are no mixed-content warnings. Ploy provisions SSL via Cloudflare automatically — it usually activates within a few minutes of DNS verification.
  • Test from a fresh browser / incognito window. DNS caches are sticky — always verify from a cold session, not your regular browser.

After cutover

  • Monitor uptime for 48 hours. Watch Ploy Analytics for unusual 404 spikes or error events. Any volume of 404s on previously valid URLs means a redirect is missing.
  • Restore your DNS TTL. Once you're confident the cutover is stable (24–48 hours), raise your TTL back to a normal value (3600 seconds / 1 hour) to reduce DNS query load.
  • Re-test all forms and integrations. Form submissions, webhook endpoints, and third-party scripts may be domain-scoped. Verify each one is firing correctly on the live domain.
  • Remove the fallback proxy when ready. Once all traffic is confirmed stable on Ploy, you can safely remove the fallback proxy rule and decommission the old host.

Need help?

If you hit a snag during migration, reach out at support@runploy.com. Include your domain and a description of what you're seeing — we'll help you get across the line.