Testing and Launch

A design is only as good as the checks that prove it works and the routine that keeps it working. This last chapter gathers the tools from the whole course into a launch gate, adds the one test that has been missing (following every link in the built site), looks at size and cost, and sets out what to watch after launch and what to do when something goes wrong. It ends with a short roadmap for the landing page at the root domain and a recap of the course.

What to Test, and With Which Tool

You have already written most of the checks. The point now is to run them together, every time, and to fail the build when one fails:

Put them in one script, in this order, cheapest first, and stop on the first failure. Run it before every deploy. The checks that depend on a server (certificates, Apache's handling of non-ASCII addresses) cannot be simulated, so they live on the launch checklist below.

The Built-Site Link Check

Every other check looks at the source or at a plan. This one follows every internal link in the finished output and confirms it reaches a file. Run on the current site, it followed about 289,000 links in 5,014 pages and found 205 distinct broken targets on 521 pages. The top of the list:

HTML Checks and Visual Checks

A link checker will not tell you that a page is malformed or looks wrong. Two inexpensive additions are worth having, and neither was run for this course:

• An HTML validator over a sample of each page type (a chapter, a cheat sheet, a kanji page). The W3C Nu validator is the usual tool. Fragments need wrapping in a page first, since they have no <html> element of their own.
• A visual sample. Open one page of each type on each site, in a narrow window as well as a wide one, in dark and print preview. Pay special attention to a language page with its accent colour, a code block with its copy button, and a table on a phone width.

The Budget: Size, Time and Cost

Exercise 2 measured the current build by the site each file would belong to:

PDFs are 79% of the bytes. The HTML is small. That changes the deployment design from Chapter 8: copying the whole build into every release wastes disk on PDFs that did not change. Exercise 2 tests an rsync option, --link-dest, which hard-links unchanged files to the previous release. Three releases of a 40 MB build dropped from 115 MB to 39 MB.

Build time is its own budget. A full build of the current site (npm run build) was timed after the course was written: 4,996 pages in about 1 minute 35 seconds in total. Write the number down, and treat a large jump as a reason to look, not a number to accept.

The Launch Checklist

For each site, in order. Nothing here is optional:

1. DNS record resolves; virtual host enabled; apache2ctl configtest passes (Chapter 8).
2. HTTPS works for every name with no warning; renewal rehearsed with certbot renew --dry-run.
3. Pre-deploy gate passes: coverage, validation, menus, solutions, secrets scan, parity.
4. Built-site link check shows no new broken target.
5. robots.txt and sitemap are right for the stage: crawling blocked while testing, allowed at launch.
6. Canonical links use the final address; the old site is not yet redirecting.
7. Redirects rehearsed as 302 on the server with curl -I, including non-ASCII and trailing-slash cases, then switched to 301.
8. Old site's menu changed to link to the new site.
9. Sitemap submitted; Search Console watched for the first weeks.
10. Rollback rehearsed once, and a restore from backup tested.

Operating the Sites

The server log is the best monitor you have, and it costs nothing. Exercise 3 summarises it (on a synthetic sample, since no real log was available): status classes, the most requested missing pages, and the number of redirects served. A routine that stays small enough to actually do:

When It Goes Wrong

• A bad release: run the rollback script. The previous release is still on disk, and the switch is one rename.
• A bad redirect rule: switch it back to 302 or remove it; the old site is still there until the area is retired.
• A certificate problem: check the renewal timer and certbot renew --dry-run first; a name missing from the certificate is the usual cause after adding a site.
• A leaked credential: change it first, then clean the content, then redeploy (Chapter 8). Do not rely on deleting the text.
• A search drop after a move: check redirects return a single 301 to the exact new page, sitemaps are submitted, and the canonical links agree. Wait several weeks before drawing conclusions.

Roadmap for the Root Domain

Once areas have moved, osztromok.com becomes a portfolio and landing page. It is the simplest site of all, and it can be built last and with the same pipeline:

1. Decide the address first: bare domain, www, or both with one redirecting to the other (Chapter 5). Everything else depends on it.
2. Content: a short introduction, a card for each site generated from the site map (so it can never list a site that does not exist), and contact details.
3. Keep the old site alive for the areas not yet moved, on its own virtual host or a path, until the last area is retired.
4. Order the remaining areas by how clean a cut each is: run the link inventory from Chapter 10 on each, start with the cleanest, and fix its existing bugs before moving it.
5. Retire the old site last, keeping the redirects for at least a year.

Hands-On Exercises

🎓 Course Complete

You have finished Learning Website: Framework & Architecture. In twelve chapters you went from asking whether the site should be split to a plan you can follow, with scripts, measurements and a rollback at each step. Here is the whole journey.