When it breaks
How a page that relies on scripts can go blank, give wrong answers silently or run code a visitor typed in, and how to read the browser's error messages.
Pages that arrive empty
Open a music festival's programme page and, for a second, you see only the logo and an empty frame. Then the line-up and the ticket prices pop in. That page's content is added by a script: the HTML the server sends is almost empty, a frame with slots and a link to the script, and the script fetches the data and fills the slots once it has loaded and run.
It works most of the time, so the risk is easy to miss. Whenever the script doesn't load, is blocked or fails, the page loses all its content. Large companies often have security tools that block scripts, and the people behind them can't switch that off. Search engines and AI assistants don't all run scripts, and those that do may not wait, so they find a nearly empty page and describe the site poorly. On a train between two tunnels, the script may never arrive. And one small mistake in an update blanks the page for every visitor at once. These visitors rarely complain, and they never show up in the team's own tests, run on fast laptops where everything works.
Content first, extras on top
If the content is in the HTML, a failed script only breaks the extras.
The fix is to send the content in the HTML itself. There are two common ways. The pages can be built in advance from the data, each time it changes, which is called a static site. Or the server builds each page on request, which is called server rendering and is what tools such as Next.js do. Either way, the festival's line-up and prices arrive with the page. Scripts then add extras on top, such as a filter by day or a map. If a script fails, the extras go and the programme stays.
A message asking visitors to turn on JavaScript is fine to keep, but it brings no content back. People behind a company's security tool can't act on it, and to a search engine it becomes the only sentence on your page.
You can check any page in a minute. Right-click, choose "View page source", and search (Ctrl+F) for a few words you can see on screen: if they're missing from the source, a script adds them. Or turn JavaScript off in the browser's settings and reload: what's left is what a blocked visitor sees.
Reading the console
When a script fails, the browser says so in the console, a panel of the developer tools (F12, then Console). Errors appear in red, in three parts: the type of error, a message saying what went wrong, and the file and line where it happened, which you can click to see the code.
Two messages turn up again and again, in code by people and AI agents alike. "Something is not defined" means a line uses a name the code never created, very often a typo: prixTotl where the code says prixTotal everywhere else. "Cannot read properties of null" means the code looked for something on the page, a button or a field, and got back null, the code's word for nothing. Either the name it looks for doesn't match the element, or the script ran too early: the browser reads the HTML from top to bottom, so a script placed at the top runs before the rest of the page exists.
So read the message before changing anything. Give the developer or the AI agent the exact message and line, and ask for that cause to be fixed. Rewriting everything throws away what works, and usually brings new bugs.
No error, wrong answer
A clean console proves nothing: check the results against answers you know.
The worst bugs say nothing. A colleague's tool for splitting the bill after a team dinner shows no error, and the total looks like a number. But enter 12 € for one person and 8 € for another, and it reads 128 €. Whatever someone types into a form reaches the script as text, and the script stuck the two pieces of text together, "12" then "8", instead of adding them. Any test that doesn't check the result will pass.
So try any tool with simple values whose answer you already know, then with awkward ones: zero, a decimal, a negative number, an empty field. When something is wrong, give the agent the inputs, the result you expected and the one you got. Then ask it to add a small automatic test that would have caught the bug, so it can't come back unnoticed. And if a tool computes a price, the amount actually charged must be calculated again on a server, never taken from the page.
Text that turns into code
Many sites show what visitors type: comments, usernames, item descriptions on a small classifieds site, the words you searched for. The page can insert that text in two ways. As text, it's displayed exactly as typed, tags and all. As HTML, it becomes part of the page's own code, which developers sometimes do "to keep the formatting". Then if someone types code instead of words, it runs in the browser of everyone who opens the page.
Developers call this an injection, or cross-site scripting (XSS). The code can do whatever the page can: change what readers see, send them to a scam, or act with the account of whoever is logged in, a moderator included. It's one of the most common flaws in sites built quickly, including by AI agents.
Deleting the offending comment fixes nothing, since the next one can do the same. Visitors' text must be inserted as text, everywhere it appears. If some formatting is needed, only a few harmless tags are allowed, and the rest is removed on the server. On a site you're responsible for, type a word between <b> and </b>: if it comes out bold, the flaw is there.
What to ask
Ask these of anyone who builds for you, and of yourself when you try a colleague's tool.
Ask what a visitor sees when the scripts don't run, and check it with "View page source": the main content should be there. Ask how updates are checked before they go live, since one mistake in a script can blank a page for everyone. When something breaks, ask for the exact error message and line before agreeing to any rewrite. When you report a bug yourself, include the message and line, plus what you did, what you expected and what you saw.
Before trusting a tool that calculates, ask how it was tested, and try it with values whose answer you know. For every place where visitors' text appears (comments, names, messages, the search box), ask whether it's inserted as text. And if a visitor's code has ever run on your site, treat it as an incident: end the sessions of the staff who viewed it, change their passwords, check what was done with their accounts, and find out whether personal data was exposed, which GDPR may require you to report.
Practise this strand
The questions on How a page is made put you in the situations this lesson describes. You answer in your own words, and you get a level, feedback and a full answer.