Build and Launch a Website with AI
Website Update Not Showing? Check the Live Deployment or Roll It Back (2026)
Use the preview URL, production domain, and deployment history to find why an AI-built site still shows old content. Roll back on Vercel or Netlify and verify the site afterward.
Your AI website builder’s preview shows the new cover image, but the link you share still opens the old one. Put the preview URL, the production URL from your hosting dashboard, and the latest deployment record side by side. Once you know which version serves visitors, you can finish publishing, check for cached files, or restore a working version.
Take a live portfolio where you’ve just replaced the home page image and changed the contact button. Check both separately. That tells you whether the whole site is on the old deployment or just one asset or feature needs attention.
Open the original project in your hosting dashboard and copy the production URL. Open the link from your résumé or profile, too, and confirm it belongs to the same project. If you use a custom domain, open both addresses and note what each one shows. See the custom domain setup guide in Chinese.
Open the deployment history. Note the time, the linked commit or upload, and whether the deployment is serving production. If the host gives each deployment its own URL, open that URL and look for a recognizable change such as the new heading or image.
| What you see | What to check first |
|---|---|
| Preview is new and the live site is old | Whether you published to production and the latest deployment is assigned to the live domain |
| The latest deployment failed | The earliest relevant error in the logs, including missing files or configuration |
| The deployment URL is new and the custom domain is old | Which project and deployment the domain is assigned to, then the cache |
| Live text changed and one image stayed the same | Whether the page references the correct image URL and the file was uploaded |
| The live site is new and the contact button is broken | The steps that reproduce the problem, then whether to fix or roll back |
Before repeatedly refreshing, open the production URL in a signed-out browser or on another device. If the second device shows the new version, check the browser cache or any offline copy on the first device. If both show the old version, keep checking which deployment serves the domain.
In v0, open Publish in the current project, check the production URL, and choose Publish Changes. If the project is connected to GitHub, check its working branch, merge, and build checks, then wait for the production deployment to finish. Preview and production URLs can point to different deployments. After publishing, check which version is assigned to the production domain. See the v0 deployment guide.
If you originally uploaded a static website folder, check that the latest files reached the same project and that the referenced images went with them. If the host reads from Git, confirm the update reached the branch and folder used for production. For GitHub Pages, see the static HTML publishing guide.
To ask an AI tool for help, give it the project name, preview and production URLs, deployment time, and a screenshot of the error. Include what you expected to see.
I changed the home page image and contact button on my portfolio. The preview shows both changes, but the live site still shows the old version. Help me check the project, deployment, and production domain in the dashboard. If the build failed, find the first relevant error in the logs. List the two changes I should verify after publishing.
If the latest deployment is already live and a form, login, or key page is broken, find a working version in the deployment history. Check its timestamp and version label to make sure it includes the features you need. If the site uses an external database, confirm the older deployment can read and write the current schema before switching.
Vercel. In the project overview, open Instant Rollback on the production deployment card and select an eligible older deployment. Check which domains will switch, confirm, and wait for the dashboard to show completion. On Hobby, you can roll back to the immediately previous production deployment. Check the dashboard for what your plan and permissions allow. Rollback disables automatic assignment of production domains. Once the fix passes testing, open Manage on the production deployment card, promote the fixed deployment, and restore automatic assignment. See Vercel’s Instant Rollback guide.
Netlify. In the original project, open Deploys, find a successful deployment that still works, and choose Publish Deploy on its details page to make it live again. If the project is connected to Git and auto-publishing is enabled, a later production deployment can replace the restored version. Use Lock to stop auto publishing to pin it while you test a fix, then unlock when the fix is ready. See Netlify’s rollback steps.
A deployment rollback changes the version that serves the site. Check your Git files and external database separately. An older deployment may also use the environment variables, API endpoints, or settings it had when it was built. When the rollback completes, open the live domain and repeat the steps a visitor would take. See Vercel’s deployment promotion and rollback guide.
- Open the home page, detail pages, and recently changed assets. Confirm visitors see the expected version.
- If the site has a contact form, submit a test entry and confirm it arrives. For member features, test signing in, loading account data, and signing out. See the form and login testing guide in Chinese.
- Fix the change in the source project, test it in preview, and publish to the original project. Check the live deployment and automatic publishing settings in the dashboard.
- Record the version that failed, the version you restored, and when you confirmed it worked. Run through the same checks in preview the next time you update the site.
If you only changed a portfolio image, start by checking the home page and the relevant project page. For a larger site, list the logins, forms, downloads, and API calls that visitors rely on. Use that list to test the next release and identify a working version if something breaks.