Why isn’t my website updating after I deployed new code?

The chain the change has to travel

A change reaches the live site by passing through a fixed series of steps. It stops at exactly one of them. Walk them in order and stop at the first one that fails; everything after it is irrelevant until that’s fixed.

Link 1: Was the edit actually made?

Open the file and look. If a coding agent did the work, don’t take its summary as proof; open the repository on GitHub, find the file, and read the line. Agents sometimes report a change they planned but didn’t write, edited a copy of the file in a different folder, or changed a similar-looking string elsewhere. If the text isn’t in the file, the rest of the chain is fine and the edit needs doing.

Link 2: Was it committed and pushed?

A change on a computer isn’t on GitHub until it’s committed and pushed. Open the repository on GitHub and look at the commits list for the branch: the newest commit should be the change, with a recent time. If it isn’t there, the change is still local. In GitHub Desktop that shows as uncommitted changes or a “Push origin” button waiting to be clicked; a developer would see it in git status. Builders that sync to GitHub have their own failure modes here: Lovable pulls only when GitHub notifies it, Bolt pushes automatically but only on changes that don’t break the build, and Replit pushes only when you click push. Commit and push, then continue.

Link 3: Is it on the branch the host deploys?

Hosts deploy the production site from one branch, normally main. A commit on any other branch produces, at most, a preview. On GitHub, check which branch the commit is on. If it’s on a feature branch or inside an open pull request, it hasn’t reached production and won’t until it’s merged. v0, for example, always works on a branch and publishes by merging a pull request into your base branch; if the pull request is blocked by a required review, so is the change.

Link 4: Did the host start a deployment?

Open the host’s deployments list. A push to the production branch should have created a deployment within a minute or two, named after the commit. If none appeared:

• The project isn’t connected to this repository or branch. Check the Git settings: Vercel under Settings, then Git; Netlify under Build & deploy, then Continuous deployment; Cloudflare under the Worker’s Settings, then Builds. A repository that was transferred to a new owner may need reconnecting.
• The host was told to skip it. Vercel has an Ignored Build Step setting, under Build and Deployment, that can cancel builds by rule, and it won’t create a new deployment for a commit it has already deployed. Netlify skips any commit whose message contains [skip ci] or [skip netlify], which a coding agent may have added.
• The host’s GitHub App lost access to the repository, for instance after the repository moved organizations. Reinstall or re-grant it. On Vercel, a commit to a private repository is only deployed if its author also has access to the Vercel project, and the free plan has a daily deployment limit.

Link 5: Did the deployment succeed?

A deployment can exist and fail. Its status will say so: Error or Canceled on Vercel, Unsuccessful (failed, cancelled or skipped) on Netlify, a failed build in Cloudflare’s build history. Open it and read the log; the last few lines usually name the problem, and that text pasted to a developer or coding agent is enough to fix it. Common causes after an edit: a typo that breaks the build, a missing environment variable, or a dependency the agent added but didn’t install. Until a deployment succeeds, the previous good one stays live, which is why the site looks unchanged rather than broken.

Link 6: Is that deployment the production one?

A successful deployment isn’t necessarily the one on the domain. Preview deployments have their own addresses and never reach it. And even production deployments can be held back: on Vercel, after an Instant Rollback, new deployments aren’t auto-assigned to the domain until you undo the rollback; Vercel labels the one on the domain “Current” and a production build that wasn’t assigned “Staged”, and either can be promoted by hand. On Netlify, a deploy locked with “stop auto publishing” stays live until you unlock or publish another. Check which deployment the host says is current for the domain, and compare its commit with yours.

Link 7: Is the domain pointing at this host?

The one people miss. If the site was moved, or set up twice, the domain may still point at a different host, and you’ve been deploying to the wrong one all along. Look up the domain’s A and CNAME records and match them against the recognition table in the diagnostic guide. A quicker tell: open the host’s own address for the deployment (the vercel.app, netlify.app or pages.dev one) and see whether the change is there. If it is, and the domain shows the old version, the domain isn’t landing on this deployment.

Link 8: Is something caching the old version?

Three caches, in order of likelihood:

• Your browser. Hard-reload, or open a private window, or use a different device. In Chrome’s developer tools, the Network panel has a “Disable cache” option that forces fresh copies while it’s open.
• A CDN or proxy in front of the host. If Cloudflare proxies the domain, its cache can keep serving old pages; purge the cache or turn on Development Mode temporarily. Vercel’s responses carry an x-vercel-cache header that says whether the page came from its cache.
• The host’s caches. Two different ones. The build cache is rarely the cause, but if a dependency or asset seems stuck, redeploy without it: Vercel’s Redeploy dialog has a checkbox for it, and Netlify’s Trigger deploy menu can retry with a cleared cache. Vercel’s data cache is the sneakier one: it holds fetched data across deployments and isn’t refreshed by a build, so a site can deploy new code and keep serving old data until it’s purged, which is done under the project’s CDN caches, not in a deployment.

Link 9: Is the content built in rather than live?

Many sites generate their pages at build time. Text that comes from a CMS, a database or an API at build time is fixed into the page until the next build, or until the framework revalidates it. So a change made in the CMS won’t appear until something triggers a rebuild, and a change to an environment variable won’t apply until the next deployment. If the edit was to content rather than code, check whether the site needs a redeploy to pick it up. Likewise, preview and production can read different environment variables, which explains a change that shows on a preview address and not on the domain.

When a coding agent made the change

The chain is the same; the difference is that you didn’t watch the early links. Ask the agent three specific questions and verify each answer on GitHub rather than in the chat: Which file and line did you change? What is the commit hash, and was it pushed? Which branch is it on? Then pick the chain up at link 4 with the host. An agent that says “deployed” usually means “pushed”, and sometimes means “edited”; the host’s deployments list is the only record that counts.

Checklist

Sources

The rules and product behaviour described above were checked against these pages when the guide was last updated. If something here has changed, these are the places to look.

• Deploying Git repositories with Vercel · Vercel
• Git settings · Vercel
• Managing deployments · Vercel
• Instant Rollback · Vercel
• Response headers · Vercel
• Site deploys overview · Netlify
• Manage deploys · Netlify
• Repository permissions and linking · Netlify
• Workers Builds · Cloudflare
• Purge cache · Cloudflare
• Development Mode · Cloudflare
• Network features reference · Chrome DevTools
• Pushing changes to GitHub from GitHub Desktop · GitHub
• Using the activity view to see changes to a repository · GitHub
• Project settings: Ignored Build Step · Vercel
• Promoting a deployment · Vercel
• Data Cache · Vercel
• Why aren’t commits triggering deployments on Vercel? · Vercel Knowledge Base
• Glossary: prerendering · Next.js
• Incremental Static Regeneration · Next.js
• GitHub · v0