Twenty compliance documents, all returning 404 - Four Star Cargo
Published
A website does not fail all at once. It fails one unowned decision at a time, and the failures stay invisible because the pages still render. Every finding below was reachable from the public site by anyone with a browser.
Terms of Service documents return 404
The registration form at /Register/Register.aspx presents a required checkbox reading "I have read and agree to the Terms of Service", linking to the Air Cargo and Ocean Cargo terms. Both targets were requested directly. Both returned HTTP 404 Not Found.
Every account opened since the files went missing was opened against terms the customer could not read, and the registration record shows the box was ticked. In a dispute the company would be relying on an agreement it cannot produce. The checkbox is required, so nobody could decline terms that were unavailable, and nothing in the interface tells staff the link is dead.
The repair is one file; the prevention is a check. Treat a legal document as a deploy-time dependency, not as content. Add a link check to the build that requests every URL referenced from a consent control and fails the deploy on any non-200, the way a missing import fails a compile. Version the documents and keep superseded versions addressable, because the agreement that matters in a dispute is the one in force on the signup date, not today's. The anti-pattern is treating those PDFs as assets that can be moved or renamed during a redesign: consent links break silently and no part of the interface reports it.
The forms library returns 404 on all 20 documents
All 20 documents listed on the Forms page return HTTP 404. Each link was requested individually. The page renders normally; the failure is observable only on request.
The list includes hazardous materials compliance, lithium battery guidance and EEI filing forms. A shipper who needs one needs it to move freight that day, and the page tells them it exists. They call instead, loading the staff the page was built to relieve, or they use a copy found elsewhere, which is how outdated compliance paperwork enters a shipment. Because the page renders, nobody internally sees a problem until a customer reports one.
Twenty documents need a watchman, not a one-off fix. Anything a customer downloads gets an availability check on a schedule, not only at deploy. A weekly job requesting every document and reporting non-200 responses is a few lines and catches this the week it happens rather than the year someone notices. Serve documents from a path a redesign does not touch, and return 410 rather than 404 for anything deliberately withdrawn, so the difference between gone and broken stays visible to your own monitoring. The anti-pattern is a hand-maintained list of links, which decays silently because nothing verifies the list against what is actually on disk.
FAQ references documents over cleartext HTTP
The FAQ page directs readers to specific form documents. Those references fall within the unavailable set and are written as http:// rather than https, which current browsers flag or block as mixed content.
The link fails twice: the browser objects to the protocol, and the file is not there either. Mixed-content warnings cost trust disproportionately, because the browser presents them as a security problem with the site rather than as a broken link, and a freight customer entering shipment details reads that warning at the worst possible moment.
Both halves of this are settled at the infrastructure level rather than link by link. Serve HTTPS only, redirect port 80 permanently, and publish HSTS once the redirect is proven, so the protocol stops being a per-link decision. Then write internal references as root-relative paths rather than absolute URLs: /forms/x.pdf cannot carry the wrong scheme, does not break when the domain changes, and works unchanged in staging. A repository search for http:// in published content finds the remainder in one pass. The anti-pattern is hardcoding absolute http:// URLs in editorial content, where they survive every migration because no framework rewrites them.
Background: SSL certificates.
Two developer credits describe different scopes of maintenance
The site carries two developer credits. WordPress-rendered pages display "Website by Universe Systems LLC". ASP.NET-rendered pages display "Website Design, Development & Platform Management by Universe of Systems". The second attributes ongoing platform management rather than the original build alone.
Two credits describing different scopes, with no single party visibly accountable, is the condition under which the rest of this list accumulates. Findings do not appear because somebody made a mistake; they appear because nobody is measured on whether they are still true. The credited firm's own domain resolves in DNS but returned no response on port 80 or 443 during testing, with a holding page in every capture from February 11, 2025 onward. That is recorded as a matter of record: a deferred internal web property is common across technology firms and supports no inference about their delivery capability.
Attribution is not accountability, and the difference is written down or it does not exist. Write the maintenance scope down and make it measurable: who is accountable, for which properties, checked how often, reporting what. A credit in a footer is attribution, not a contract, and the two are routinely confused. Reduce the surface before buying more hours, because consolidation removes work permanently where hours only schedule it. The anti-pattern is the standing retainer with no defined checks: it bills continuously while nothing verifies that the site still does what it did last year.
Assessment of cause. The evidence is consistent with constrained maintenance capacity, not defective work. The estate is four domains, two web servers, three page-building frameworks, a WordPress installation on PHP 8.1, which left security support on 31 December 2025, and a separate ASP.NET Web Forms application holding live customer accounts. Unreplaced document links, an unmaintained legacy layer and absent validation on one form are what a maintenance surface larger than the available hours looks like. Any provider inherits the same arithmetic.
Background: domain vs hosting vs website.
Core Web Vitals assessment failed on mobile and desktop
Core Web Vitals is assessed from aggregated field data collected from Chrome users over a rolling 28-day window and is an input to search ranking. The assessment failed on both form factors. Largest Contentful Paint measured 5.3 s on mobile and 4.6 s on desktop against a 2.5 s target.
This is field data, not a laboratory score, so it is what visitors actually experienced rather than a number to argue with. It is also an input to ranking, which compounds: the site places lower, so it receives fewer visitors, and the ones who arrive wait five seconds. At that duration a substantial share never see the page at all, and the loss is invisible in analytics because a visitor who leaves before the page renders is frequently never recorded.
The number moves when its cause moves, so start where the measurement points. Measure field data before touching anything, because lab scores and real users disagree constantly. Then work in order of what the measurement blames: server time first, then render-blocking resources, then image weight. Set a performance budget in the build and fail on regression, since a passing assessment is only ever one plugin away from failing again. The anti-pattern is optimising images on a site whose server takes three seconds to answer, which is effort spent where the measurement is not.
Background: website design.
Every page sampled exceeded the server response target
To establish whether the field data reflected a single slow page, every internal link on the home page was followed and time-to-first-byte recorded. All ten pages returned HTTP 200 and all ten exceeded the 0.8 s target. The home page measured 3.00 s.
Time-to-first-byte is server time, spent before a single byte of the page reaches the browser. Three seconds is gone before any front-end work can begin, which places a ceiling on the Core Web Vitals result that no amount of image or script optimisation can lift. Ten pages out of ten also rules out one slow template: this is the platform, not a page.
Ten pages out of ten is a platform result, and it is diagnosed as one. Sample every page rather than the home page, because the home page is usually the only one anybody profiled. Put a cache in front of anything that renders per request; a brochure page that changes monthly has no reason to be assembled from a database on every visit. Better still, render it once at build time and serve a file. The anti-pattern is diagnosing performance from a single URL, which is how a platform-wide problem gets recorded as a slow home page.
Three technology stacks operate under one domain
Web server: Microsoft IIS 10.0, a non-standard host for WordPress, which targets Linux and Apache. Public site: WordPress with Divi, 916 Divi references in the home page document, the principal contributor to the measured response times. Registration: ASP.NET Web Forms 4.0.30319.
Three stacks mean three update cadences, three sets of security advisories and three ways to break, maintained by whoever is available. It also means no single person can reason about the whole system, so changes are made locally and their consequences appear somewhere else. The 916 page-builder references are not a style problem: that markup is parsed and executed on every request, and is the measured cause of a home page that takes 3.00 s to return its first byte.
This is an architecture decision, which means it is reversible. Match the technology to what the page actually does. A brochure site is documents, so build it as documents: hand-written markup or a static generator, rendered once and served as files, with no database and no page builder in the request path. Keep the application that genuinely needs an application, and give it its own hostname so its runtime, its updates and its incidents are separable from the marketing site. The anti-pattern is installing a page builder to avoid writing markup and then paying for it on every request forever.
Background: static sites vs a CMS.
The legacy application layer is unmaintained and indexed
Example endpoint: /ConsentToScreenEmail.aspx, indexed by Google under the title "About Four Star Cargo Inc.". The page served is an E.E.I. filing consent form. It instructs the reader to copy "the blue text below" into an email; no such text is present. The stated subject line is empty.
Search engines index it, so customers reach it directly without ever seeing the current site. They then follow instructions that reference content which is not on the page. Web Forms was never carried forward to .NET Core or .NET 5 and later, so this layer has no upgrade path that is not a rewrite, and it holds live customer accounts reachable from the open internet and listed in search results under a title that suggests it is an About page.
An unmaintained layer is a scope problem before it is a security one. Inventory what is actually reachable before deciding anything, because an unmaintained layer is usually larger than anyone remembers. Then take each endpoint one of three ways: repair it, migrate it to the supported stack, or remove it and return 410. Google states it treats 410 and 404 the same, so the value is in documenting intent for your own monitoring rather than in the status code itself. Anything left running on an unsupported runtime needs a migration date on a calendar. The anti-pattern is leaving a legacy application indexed and reachable because nobody is certain who still uses it: that uncertainty is answerable from server logs in an afternoon.
The quote calculator prices impossible shipments
The calculator on the Quotes page performs no input validation. Weight -100 lb, dimensions -15 x -18 x -82 in. The entry was accepted and summarised as "-100 lbs (-133 lbs dimensional)". A second case, zero pieces at zero pounds, returned a quote of $8.32.
This is the site's primary commercial function and its most prominent call to action. An engine that returns a number for input that cannot exist gives no reason to trust the numbers it returns for input that can. A quote is also a commercial statement: a figure a customer can screenshot and hold the company to, produced here by arithmetic nobody checked.
A figure a customer can hold you to needs the rigour of a payment. Validate on the server, always, and treat browser-side validation as a convenience rather than a control, since anything enforced only in the browser can be bypassed by anyone who opens the developer tools. Constrain each field to a physically possible range, reject rather than coerce, and return an error the customer can act on instead of a number. Where a calculation produces a commercial commitment, cover it with tests using boundary values: zero, negative, and absurdly large. The anti-pattern is validating only in JavaScript and trusting whatever reaches the endpoint.
The primary conversion control does not go anywhere
The "Free Quote" control in the sticky top bar carries an empty href attribute. Browsers resolve an empty href to the current document, so the control reloads the current page. Confirmed on the home page and on /about/; it is template markup and behaves identically site-wide.
It is the most prominent call to action on every page of the site, and it has never worked. The failure mode is also the worst available: the page reloads, so the visitor cannot tell whether they mis-clicked or the site is broken, and many will try twice before leaving. Every visitor who wanted a quote and used this control was lost, on every page, for as long as the template has been live.
One attribute caused this, and one check prevents the next one. Never ship an anchor with an empty href; if a control has no destination yet it is a button, and a button with no handler should be visibly disabled. Add a build check that fails on empty or placeholder href values, because this class of defect is invisible in review and obvious in code. Then cover the conversion path with one end-to-end test that clicks the control and asserts the destination, since this is the single control whose failure costs revenue directly.
Rendering defects and a failed icon font
The home page sub-hero image renders with a vertical discontinuity through the graphic. Button hover states emit stray arrow and speaker glyphs, indicating a failed icon-font load. Missing pages return the WordPress default "No Results Found" template with no navigation back to services.
Individually trivial, collectively a signal. A shipper comparing three freight forwarders reads these as how carefully the company works, and freight is a business bought on reliability. The 404 template is the costly one: it strands a visitor who was already looking for something specific, with no route onward, which turns a broken link into a lost enquiry.
Two of these are cosmetic and one loses enquiries, so start with the 404. Give the 404 page the same care as a landing page: state plainly that the page is gone, offer search, and link the main services. Self-host icon fonts or inline the icons as SVG so a third-party outage cannot leave stray glyphs across the interface, and always declare a fallback so a failed font degrades to nothing visible rather than to the wrong character. The anti-pattern is shipping the framework's default 404, which is written to fit every site and therefore helps on none.
Mobile layout overlaps and scrolls sideways
At 412 px on /barrel-2/, a service page linked from the home page, the logo and page heading overlap by 19 px measured, and document width is 432 px against a 412 px viewport, producing horizontal scroll.
Horizontal scroll on a phone is the clearest available signal that a site was never opened on one. It affects a service page linked directly from the home page, so it is on a path visitors actually take, and mobile is where most freight enquiries begin. Overlapping text also makes the heading partly unreadable, which is a content failure rather than a cosmetic one.
The width that failed is the width most visitors arrive at. Test service pages at 390 and 412 px, not the home page, because the home page is usually the only one that was checked. Horizontal overflow has a small number of causes worth checking in order: a fixed width, a wide table, a long unbroken string, or a negative margin. Assert it in the build by comparing document scroll width against viewport width at two widths, which catches the regression rather than a person noticing it. The anti-pattern is treating mobile as a final pass over a desktop layout instead of the width most visitors arrive at.
Compliance guidance published as a dated blog post
The Haz-Mat link resolves to a post dated May 13, 2020, attributed to "admin", carrying a comment counter and blog sidebar. The same sidebar exposes a published post titled "x", dated January 1, 2020.
Hazardous materials guidance is compliance content, and presenting it as a six-year-old news item with an author called admin makes it read as stale whether or not it is. A shipper cannot tell from the page whether the guidance is current, which is the one thing compliance content has to communicate. The stray test post beside it tells every visitor that nobody reviews what is published.
Compliance content and news carry different obligations, so they need different homes. Separate reference content from news. Compliance guidance belongs on a versioned page carrying an effective date and a last-reviewed date, with no author byline, no comment counter and no blog chrome, because each of those signals that the content is an opinion from a moment rather than a standing rule. Set a review interval and record it on the page. The anti-pattern is using the blog as a general publishing tool because it is the easiest thing in the CMS to add a page to.
An associated domain is a mirrored copy of a staging server
Website-copier signature in page source: present, 4 occurrences. References to the staging host in live code: 12 references. Security headers: none present. The production site issues AJAX and REST calls to staging.safe.sx.
A production site calling a staging host depends on a machine nobody promised to keep running, and staging hosts are switched off routinely because that is what they are for. When it goes, production breaks in ways nobody predicted, because nobody knew the dependency existed. Absent security headers on the same property leave it without the defences a browser will apply for free if asked.
A copied site inherits its origin, which is why this cannot be patched. Rebuild rather than copy. A site duplicated with a copier tool inherits every absolute URL it was built with, and those URLs point wherever the original was running. Use relative paths so an environment cannot be baked into the output, and add a deploy check that fails on any reference to a staging hostname. Set the security headers at the same time, since Content-Security-Policy, X-Content-Type-Options and a frame policy are configuration rather than development work. The anti-pattern is a website copier as a migration strategy: it produces something that renders and depends on a machine you are about to decommission.
A bare domain refuses HTTPS, and an unpinned dependency
https://www.atsmia.com resolves correctly while https://atsmia.com is refused at the transport layer, leaving the bare domain unreachable over HTTPS. The site loads an icon library from a third-party CDN pinned to "latest". A fourth domain, complete.cw, returned no response on ports 443, 80, 8080 and 22; all connections timed out after 15 s, while control hosts connected in under 0.3 s.
Most people type the bare domain, so the form that fails is the form most visitors use, and the failure is at the transport layer, which means no redirect can rescue it. A dependency pinned to "latest" means an upstream change takes effect on your site without anyone reviewing it, which is a supply-chain exposure as much as a stability one. The unreachable fourth domain is linked from the site and described in its own copy, so a visitor is being sent somewhere that does not answer.
Two separate problems on one property, each with a settled answer. Issue the certificate for both the apex and the www host, serve both, and redirect one to the other permanently so there is a single canonical form. Pin every third-party dependency to an exact version you chose and update it deliberately, or self-host it, which removes the third party from the request path entirely. Check the whole estate rather than the main site, because associated domains are exactly where nobody is looking. The anti-pattern is testing only the www form, which passes while the address most visitors type does not.
Background: IP addresses and DNS.
What was already correct
Mail was the part that held. SPF publishes a single scoped provider with a hard fail and no stale mechanisms, DMARC is published with reporting addresses configured, and the primary domain carries a valid certificate with the apex redirecting to HTTPS. Shipment tracking works. None of that needed touching, which is why the remediation is smaller than the finding count suggests.
Bottom line
A page that renders looks identical to a page that works. Nothing on this estate was checking the difference, which is why fifteen findings were true for years before anyone looked.