Choose the version that matches the incident
Review the deployment history and identify the last version that worked for the affected pages or behavior. Compare its timing with the change that introduced the problem. If the site has several types of content or routes, verify that the candidate version contains the expected files before selecting it.
If the issue affects only part of the site, determine whether reverting the entire deployment is acceptable. A rollback may also remove improvements included in that release. Record the current version and the reason for reverting so you can return to it if the suspected regression is unrelated.
Restore first, investigate second
After selecting the earlier version, open the published address and repeat the checks that exposed the problem. Confirm that the expected page, assets, and important interactions work again. If a custom domain is involved, test it separately from the service's published address so DNS or certificate issues are not mistaken for a file regression.
Once visitors can use the restored version, compare the newer deployment with the known-good one and isolate the change that caused trouble. Correct and test that change before deploying it again. Keeping rollback and diagnosis as separate steps gives you a stable release while you investigate without guessing at a fix in production.