--- title: Seven free tools we open when a site breaks description: The free tools we reach for first when a site looks broken, and what each one actually tells us about where the real problem is hiding. date: 2026-10-16 updated: 2026-10-16 tags: [friday roundup, troubleshooting, free tools] url: "https://drivenhost.com/blog/free-tools-when-a-site-breaks" author: DrivenHost --- Most "my site is broken" messages arrive the same way. Something looks wrong, and nobody is sure yet whether the fault is in the site, the browser, the network, or on our side. Before we touch anything on a server we work through a short list of free tools, because five minutes of checking beats an hour of guessing. None of these cost anything, none of them need an account, and all of them have been around long enough that we trust what they report. Here are the seven we end up opening most weeks. ## The browser console A blank page or a layout that loads halfway almost always leaves a red line in the browser console, and that line usually names the file causing it. Scripts loading over plain HTTP on an HTTPS page show up here too, which explains a surprising number of "the padlock disappeared" reports. The console is built into every major browser, and the [Chrome DevTools documentation](https://developer.chrome.com/docs/devtools/) is a decent tour if you have never opened it. We ask customers for a screenshot of this panel more than any other. ## The network tab Sitting beside the console, the network tab tells us what the server actually answered for every request on the page. A 500 means something failed in PHP and there will be a matching entry in the error log. A 403 is usually a security plugin or a firewall rule, and a 404 on a stylesheet is why the site suddenly looks like plain text. It is also the fastest way to spot one slow third-party script holding up everything else, which is a different problem from a slow site. ## A private window and a second device Half the "the site is down" reports we investigate turn out to be one cached copy in one browser. A private window loads the page with no cache, no cookies, and no logged-in session, which is what your visitors actually see. If it looks fine there, the problem is local. If it looks broken everywhere, including on a phone on mobile data, check our [status page](/status) next and then keep digging. ## The raw page source Page source shows what the server sent, before any JavaScript rewrote it. That distinction matters when a page looks right to you but search engines see nothing, or when a plugin injects a redirect you cannot find in the dashboard. On the command line, `curl -I https://example.com` prints just the response headers, which is how we untangle redirect loops and stale cache headers in a few seconds. Our notes on [broken links and 404s](/blog/broken-links-and-404s) cover what to do once you have found one. ## SSL Labs When a browser complains about a certificate and cPanel insists one is installed, the [SSL Labs server test](https://www.ssllabs.com/ssltest/) usually finds the reason. The common one is a missing intermediate certificate, which many desktop browsers paper over and most phones do not, so the site works for you and fails for a customer. The test also reports the expiry date and which protocols are enabled. We wrote more about what the padlock does and does not prove in [SSL beyond the padlock](/blog/ssl-beyond-padlock). ## The W3C Nu HTML Checker Page builders and half-finished theme edits leave unclosed tags behind, and an unclosed `div` can push a footer into the middle of a page or swallow a sidebar whole. The [Nu HTML Checker](https://validator.w3.org/nu/) finds those in one pass. Ignore the pedantic warnings and read the errors near the part of the page that looks wrong. It is not a quality score, so do not chase a clean report for its own sake. ## The Wayback Machine When a site owner tells us nothing changed and the evidence says otherwise, [the Internet Archive](https://web.archive.org/) often has a copy of the page from before it broke. Comparing last month's source against today's answers the question faster than any amount of back and forth. It is also the only backup some people turn out to have of content they deleted years ago, which is a sobering thing to discover during a support call. None of this replaces reading the error logs, and it will not fix a plugin conflict for you. What it does is narrow the problem down to one layer before anyone starts changing settings, which is the part that usually saves the afternoon. If you have worked through the list and the answer is still not obvious, send us what you found and [open a ticket](/support). A console screenshot and a note saying what you already ruled out gets a useful reply from us much faster than a message saying the site is broken.