Choose the version to restore
Review the deployment history and locate a version that was serving the site correctly before the issue began. Compare its creation time and changes with the current release, and confirm it belongs to the same project and environment. A rollback should target a known-good deployment, not simply the entry immediately before the current one if that version was already faulty.
Think about changes outside the deployed files as well. A release may depend on a database change, a domain update, or a connected service setting that rollback does not reverse. If those dependencies changed, plan how they will remain compatible with the earlier code before switching traffic.
Apply the rollback and check the result
Use the hosting rollback action for the selected deployment and wait for the platform to report its outcome. Then open the public site and check the pages or actions related to the reported problem. Confirm behavior from the user perspective rather than relying only on a successful deployment status.
If the earlier version does not resolve the issue, record which deployment is active and what you observed before making another change. Preserve the failed release details for diagnosis, and avoid repeatedly switching versions without identifying a cause. After recovery, prepare a corrected release and verify it in a controlled way before replacing the restored version.