Sam reported that the hero section on the /locations/ hub page (https://aguiarinjurylawyers.com/locations/) was showing a solid dark color instead of the background image that used to be there. The session focused on diagnosing why the hero background image was not rendering for Sam, even though it appeared to render in cloud-based browser testing environments.
Used a browser automation agent to open the page and inspect the hero section's DOM and CSS in detail. Findings:
Hero HTML Structure:
<section class="sal-hero">
<img class="sal-hero-img"
src="<https://aguiarinjurylawyers.com/wp-content/uploads/2026/03/welcome-to-kentucky.webp>"
width="1920" height="1080" loading="eager" decoding="async">
<div class="sal-hero-overlay" aria-hidden="true"></div>
<div class="sal-hero-inner"><!-- heading, subheading, CTA --></div>
</section>
Key CSS on .sal-hero-img:
position: absolute;
top: 0;
left: 0;
width: 100%;
height: 100%;
object-fit: cover;
object-position: center;
z-index: 1;
No display:none, visibility:hidden, or opacity:0 found on the image element. The CSS is correct.
Overlay CSS (.sal-hero-overlay):
position: absolute;
inset: 0;
background: linear-gradient(to top,
rgba(11,33,45,.72) 0%,
rgba(11,33,45,.58) 70%,
rgba(11,33,45,.38) 100%
);
z-index: 2;
The overlay is semi-transparent dark navy gradient. It sits above the image (z-index 2 vs 1) but should not fully obscure it.
Hero fallback background color: #0b212d (dark navy/teal). This is what shows if the image fails to load.
When the image URL was tested via curl (no Referer header), the server returned HTTP 403 Forbidden. The image only loads when requested with the correct same-origin Referer header from the website itself.
The image file itself is valid: 205,608 bytes (~200KB), .webp format, uploaded March 2026 to /wp-content/uploads/2026/03/welcome-to-kentucky.webp.