Check the release before upload
The first gate should catch failures that can be detected without touching production. The KubeInfra workflow confirms it is deploying the production branch and lints every PHP file in the theme. That does not prove the site works, but it prevents a known class of broken releases from being activated.
Keep runtime configuration separate
The release contains theme code and public assets. Deployment secrets and site-specific runtime values come from protected workflow settings and are installed outside the version-controlled theme files. This makes a code review useful without exposing operational credentials. A deploy should fail if a required setting is absent.
Activate, then test public URLs
After uploading the theme, the workflow activates it and requests the live homepage, contact page, sitemap and robots file. It checks for expected content rather than treating an SSH exit code as proof of a working website. A stronger check can also cover a critical user journey and the assets that journey depends on.
- Request the exact public host visitors use
- Check the status, content and canonical URL
- Inspect important CSS, images and the root favicon
- Record a rollback path before a risky release
Understand the limit of a green result
A handful of smoke checks cannot prove every route, form delivery or future edge-cache response. They do give the team an immediate signal when a common path is broken. Follow a deployment with a short manual review of changed pages and a clear owner for any later alert.
The favicon lesson
Our theme originally linked the right KubeInfra image, but the root /favicon.ico URL still redirected to a WordPress image. Browser tabs and search results can use different icon paths, so the fix had to be verified from the public root URL. That small issue is a useful reminder: check the behavior the user or crawler actually sees.
Read the platform build