FlowHaxa has broken badly before. Earlier in the build, the whole site returned a 500 error, and the cause was one missing ] in a configuration array. That one was loud. Everyone who visited saw it.
The problems in this post were quiet. Nothing was down. Every page loaded. The site looked finished. But when I checked the live sitemap against the build on October 11 and ran it through PageSpeed Insights, the foundation turned out to have more cracks than the content did.
How I looked
The audit used three checks, and none of them needed special tools:
- The live sitemap against the build. Every URL in the sitemap should exist in the build, and every page in the build should be in the sitemap. Mismatches point to dead links or orphaned pages.
- A crawl of the rendered site. Not the source files, the pages as a browser receives them. That's where broken links, missing canonical tags and duplicate addresses show up.
- PageSpeed Insights on mobile. It measures a simulated mid-range phone on a slow connection, which is closer to a real reader than my own desktop.
Problem 1: Two copies of the same site
flowhaxa.com and www.flowhaxa.com both served the full site. Neither redirected to the other, and each page told Google it was the original. The homepage and seven policy pages had no canonical tag at all. On top of that, /about/ and /about were two separate addresses for the same page, and five articles linked to pillar pages using the trailing-slash version.
For a reader, none of this is visible. For a search engine, it's several copies of every page competing with each other for the same ranking.
The fix: one address. Every request for flowhaxa.com or http:// now gets a permanent 301 redirect to https://www.flowhaxa.com, the address in the sitemap. Every page carries a canonical tag on that host. Trailing-slash URLs redirect to the clean version, and the five articles link to the clean address directly.
Problem 2: Links to articles that never existed
Two internal links pointed to /article/50-30-20-rule-cash-flow and /article/zero-based-budget-maximize-cash-flow. Neither article was ever published at those addresses. The answers existed, as short answers in the FAQ section, just under different slugs. Anyone who clicked got a 404.
The fix: both links now point to the real answers. It took two minutes. Finding them took a crawl of the rendered site, because links like these look fine in the source.
Problem 3: Images on someone else's servers
FlowHaxa uses six Creative Commons images from Wikimedia Commons. All six loaded directly from Wikimedia's servers, at full size, on every page that used them. One photo, of a businesswoman at a laptop, appeared on 28 different guides.
The fix: the images now live on FlowHaxa itself, as WebP files at three widths so phones download the small one. Each guide uses the image that fits its topic, so each image now appears on 7 to 13 guides instead of one carrying 28. Every image has descriptive alt text. The license for these images requires saying what was changed, so the Image Credits page now lists the edits.
Problem 4: A slow phone experience
Live mobile PageSpeed was 65. First Contentful Paint took 4.7 seconds and Largest Contentful Paint took 6.0 seconds on the simulated phone. The causes were ordinary:
- Five font files loading from two outside servers before any text could appear.
- The AdSense script and a second heading font loading in the page head, competing with the page itself.
- An unminified stylesheet, and no browser caching rules, so returning visitors downloaded everything again.
The fix: the body font, Inter, is now one 31 KB file served from FlowHaxa. AdSense and the heading font load after the page finishes or on the first interaction. The stylesheet is minified, and fonts, CSS and images now carry long cache lifetimes.
| Mobile PageSpeed | Before | After |
|---|---|---|
| Performance score | 65 | 99 |
| First Contentful Paint | 4.7 s | 0.9 s |
| Largest Contentful Paint | 6.0 s | 1.1 s |
The 99 is a live PageSpeed Insights mobile run after the upload, not a local test.
Problem 5: Promises marked Coming soon
The calculator page showed three cards marked Coming soon: working capital, emergency fund and debt payoff. The small-business guide had a fourth, for e-commerce sellers. A Coming soon card looks like a plan to its builder. To a reader, it looks like a dead end.
The fix: all four were built. The debt payoff calculator compares the avalanche and snowball methods for up to 10 debts. Before it went live, I checked it against a hand-worked textbook case: it has to match to the month and to the dollar of interest. Each calculator page has an explanation and a FAQ, and they're all in the sitemap and site search.
The bug that wasn't
One finding from the audit didn't hold up. A local test showed new articles missing from the site, which looked like the article cache wasn't refreshing on the server. FlowHaxa does cache its article index for an hour, so it was plausible. But the stale cache file came from my own test run, not from the live site. The real server was fine.
I'd already written it up as a bug. I took it out of the notes instead of fixing something that worked. A wrong diagnosis that gets fixed anyway costs more than the time: it adds code nobody needed and hides the real cause the next time something breaks.
Why quiet problems cost more than loud ones
The 500 error got fixed fast because it was impossible to miss. The problems in this post could have run for months. Duplicate hosts split ranking signals without any warning. A slow mobile page loses readers who never complain, they just leave. A dead link only fails for the one person who clicks it, and they don't report it either.
That's the case for auditing a site that seems fine. A broken site tells you it's broken. A site that works but leaks only shows it in the numbers, and only if you go looking.
The checklist that came out of it
- Type the domain four ways (with and without www, http and https) and make sure all four end at the same address.
- View the source of the homepage and confirm there is exactly one canonical tag.
- Crawl the rendered site after each deploy. Broken links hide in the source.
- List everything that loads from another server. Each one is a delay you don't control.
- Don't publish a Coming soon card. Ship it or leave it out.
- Run
php -lon configuration files before upload. That one is from the bracket. - Before you fix a bug, confirm it exists on the live site and not just in your test.
The pattern across the network
This is the third time the expensive problems in this portfolio turned out to be small and structural. DryOutHub's was one line in robots.txt. Three other sites shared the same bug because they shared the same template. FlowHaxa's was a missing bracket, then a missing redirect. None of it was about content quality. All of it was about process.
The FlowHaxa project page tracks the current state, and website redesign covers how I approach fixes like these without starting over. The next post looks at the content itself: 29 in the middle, 5 at the end.