Web Operations
Static Site Deployment Verification Checklist for Small Teams
A practical checklist for verifying static site deployments, public URLs, internal links, and screenshots before reporting a release as complete.
Search intent: the build passed, but the public site still needs a real check
A static site deployment can look finished in the terminal while the public page still needs an operational review. The build may pass, the commit may be pushed, and the CI job may be green, but a visitor only sees the final URL, the title in the browser tab, the first screen, links, images, and forms. That visible result is what should be checked before the release is treated as done.
For small teams, the useful habit is a short deployment verification checklist. Open the main company page at https://sambro.space/, the browser tools index at https://tools.sambro.space/en/tools, and the blog index at https://blog.sambro.space/ after the release. Then confirm that the page you changed is reachable, readable, and connected to the rest of the site.
Start with the exact URL that changed
Do not verify only the homepage unless the homepage was the change. Open the exact route that was added or edited, including its language path when the site has more than one locale. A blog post, a tool page, a game page, and a company contact page can all be deployed by the same pipeline but fail in different ways: missing metadata, stale links, broken assets, or a route that was not generated.
Copy the final public URL into the release note or ticket after checking it. If the URL contains query strings, Korean text, or a redirect value, inspect it carefully before sharing. A URL utility such as https://tools.sambro.space/en/tools helps separate the path, query values, and encoded characters so the verification note does not spread a fragile link.
Check what search engines and users both see
A deployment check should include the visible page and the metadata that search results may use. Confirm the H1, title, meta description, canonical URL when available, and language links if the page supports multiple languages. If the page is a blog post, make sure the description matches the actual checklist or guide, not a copied default from another page.
Then scan the first screen like a user. The CTA should lead somewhere useful, the internal links should match the language of the page when possible, and the page should not rely on a private or preview URL. If the release includes Markdown-style content, preview notes with https://tools.sambro.space/en/tools/markdown-preview before copying them into a public post.
Verify links, images, and screenshots without over-testing the whole site
Small releases do not need a full manual audit of every route, but they do need the paths touched by the change. Click the primary CTA, one related internal link, and any tool or company link mentioned in the new content. For image changes, check that the file loads on the public page and that the dimensions look intentional on a narrow screen.
If you attach a screenshot to a release report, crop private browser context and reduce oversized files. The image compressor at https://tools.sambro.space/en/tools/image-compressor is useful for keeping screenshots light enough for tickets and chat threads. A clear small screenshot is usually better than a huge full-desktop capture.
A concise release note pattern
A practical deployment note can be very short: changed file, public page checked, build result, CI run status, and any known limitation. If something is still queued, say queued or in progress with the run ID instead of guessing that it will pass. If a dirty local file existed but was not part of the release, say it was excluded so the next operator understands the repository state.
For the Sambro workflow, keep links tidy: company context at https://sambro.space/, tools at https://tools.sambro.space/en/tools, and blog content at https://blog.sambro.space/. The useful standard is simple: build passed, exact public route checked, internal links reviewed, metadata matched, and the deployment note gives the next person enough evidence without demanding a meeting.