A green npm run build is reassuring. It can also be a little misleading.
The build confirms that the project can generate pages. It does not confirm that the right domain responds, a form reaches its destination, the navigation works with a keyboard or Google can find the version you meant to publish. Those are different questions, and they tend to show up when reopening the project is least appealing.
At first, my release review was fairly vague. I opened the homepage, checked that nothing looked broken and assumed the rest was fine. Once my portfolio grew to include two language versions, a generated sitemap and its own headers, I realised publishing is not a final click. It is a change in the kind of problem you are solving.
This is the review that helps me avoid missing the basics. It is not meant to fit a landing page, a shop and an app with users in the same way. It is a way to ask better questions before sharing a URL.
I start with the page someone will see first
I do not start with Lighthouse or the code. I open the final URL in a private window and move through the website as if somebody had just sent it to me.
I check whether the main message makes sense without context, whether links lead to real pages and whether any placeholder text is still there. I review buttons, contact details, browser tab titles and images that might still be a test version. An unfinished page usually gives itself away quickly on that pass.
Then I try to find an important page without using the address bar. On a portfolio, that might be a project; on a service website, a particular service; on a blog, a recent article. If I can only reach it because I know the structure from the inside, the navigation needs work.
It is not a sophisticated check. It is one of the most useful ways to avoid publishing a website that is technically finished but leaves people wondering what to do next.
I test what only shows up when it fails
Forms need a real production test. It is not enough for the browser to flag a required field or for a pleasant message to appear after pressing the button.
I send a test submission and confirm it reaches the right place. I also look at what the website shows while it sends, what happens when there is an error and whether someone can fix a value without starting over. None of that is spectacular, but a person trying to contact you should not be the one to find out the form was not working.
There is one quick check I do not skip. I navigate the form with Tab. Fields need clear labels, focus needs to be visible and errors need to say what has to change. A field explained only with a placeholder can seem enough in a mock-up, but it does not hold up well in a real interaction. My basic accessibility guide covers this in more depth.
Browser validation is useful for guidance. The validation that decides which data an application accepts belongs on the server. Before launching a form, I would also review which data it asks for and whether it needs to ask for it. In web form security, I explain why without turning every form into a cybersecurity problem.
I put the mouse aside for a moment
Navigation can look flawless until you try it without a mouse. In a narrow window, I check that there is no horizontal scroll, the menu does not cover content and buttons remain comfortable to press. Then I use Tab to move through links, buttons and menus.
I am not trying to complete a full audit in ten minutes. I am looking for obvious failures. Invisible focus, a strange tab order, a dropdown that cannot be closed or an action that depends on hover are reasons to stop and look again.
I also check headings and content. A page can use large text everywhere and still not have a hierarchy that helps people read it. If an image contains information, it needs an alternative; if it is decorative, it should not create noise. These choices are easier to make while you are still publishing than once twenty pages follow the same pattern.
I look at the website the browser receives, not the one I imagined in Astro
On a static project, there is a useful difference between source code and what is actually published. Before an important launch, I open the generated HTML of a main page and inspect the <head>.
On my portfolio, I check that title, description and canonical match the page. Since the site is in Spanish and English, I also check hreflang relationships and the sitemap. There is no point in having routes correctly mapped in the repository if a published version points to a URL that does not exist.
You do not need to add every possible tag. What matters is that what you have is coherent. A public page with accidental noindex, a canonical pointing elsewhere or a sitemap full of URLs you do not want to show can cause problems that are harder to spot than a broken link. My portfolio’s technical SEO and the article on hreflang explain the decisions behind that review.
A sitemap can help Google discover URLs. It does not force Google to index them or place them high in results. Keeping that distinction in mind stops you from publishing a page and expecting the XML to do the rest.
I review every request a visit brings with it
Before I sign off on a page, I open browser developer tools and look at which resources it downloads. This habit has helped me more than chasing a score.
Images usually provide the first answer. A large cover served to a mobile device, several fonts barely used or a third-party script nobody needs are costs that come with every visit. They do not always have to go, but there should be a reason to keep them.
I also review external services. Analytics, maps, videos, chat and tracking pixels affect performance, privacy and sometimes the website’s security policy. In my deployment configuration, for example, the CSP has to allow only the connections and resources my portfolio actually uses. Copying a policy from another website can break resources; leaving it wide open makes it less useful. That is what I explore in web security headers.
Privacy belongs in the same conversation. If a tool collects data before someone agrees to it, a cookie page does not fix the actual loading order. I first understand what runs. Then I decide whether it belongs there and how to explain it.
What I prepare for after launch
Some checks only make sense once the site is receiving visits. During the first days, I review key routes, form submissions and errors that the deployment platform may report.
If I have access to Search Console, I submit the sitemap and inspect one or two priority URLs. Not to force immediate results, but to see whether Google can access the page as expected. If a URL is not indexed, it is better to separate discovery, crawling and indexing before changing things at random.
The other source of information is simpler. Repeated questions, people unable to find a page or links that lead somewhere unexpected. All of that reveals places that were clear to the person who built the website and less clear to the people using it.
Publishing does not end the review
I do not apply this review at the same depth to every project. A landing with no form, analytics or dynamic content does not need the same pass as a bilingual site with several routes. The point is to match the review to the risk, not add tasks because they look good in a document.
But I keep the order. First, confirm that what people will see works and makes sense. Then check that the experience does not leave out people who navigate differently and that technical signals match what I want to publish. Finally, observe what happens once the website leaves my computer.
That is what turns a release into a careful delivery for me. Not a perfect website. A website where you have checked enough not to leave the most predictable failures to the first person who arrives.