An HTML banner opens on the design team's preview site. The same files go to a different preview address and render as a white rectangle. Start with the requests the browser actually made. A preview at /qa/banner/ gives relative URLs a different starting directory from a preview at /. The top-level page can load while a stylesheet, script, or image resolves to a path that the new host never received.
Open the actual preview address
Use the address the next reviewer will receive. Include the full path and notice whether it ends in a slash. At /qa/banner/, assets/tile.png resolves to /qa/banner/assets/tile.png. At /qa/banner with no redirect, the same reference resolves to /qa/assets/tile.png. A leading slash changes the result again. /assets/tile.png starts at the origin root in either case. MDN's guide to resolving relative URLs explains how the browser selects that starting directory.
Look at the page address after navigation finishes. A host may redirect the no-slash URL to the slash URL, which makes both entry points behave like the latter. If the page has a base element, compare its declared URL with the final page address. The console expression new URL('assets/tile.png', document.baseURI).pathname is a quick check for a reference in the HTML. Use the actual network request to confirm the URL for a resource loaded from a stylesheet or script.
Identify the first request that went wrong
Open Chrome's Network panel before reloading. Turn on Disable cache while DevTools is open, clear the current rows, and reload the preview. The Chrome DevTools Network guide shows how to inspect a request's headers, response, and initiator. Filter first by the filename that should appear, then note the requested URL, the final URL after redirects, and the response status and content type.
Suppose the network log shows /assets/tile.png with a 404, while the uploaded file sits at /qa/banner/assets/tile.png. That is enough evidence to change the reference to assets/tile.png for an HTML entry point at /qa/banner/. Check the file name's capitalization too. A file called Tile.png can open on a case-insensitive development machine and fail on a case-sensitive host. Match the path in the delivered package exactly.
Inspect suspicious 200 responses as well. Some preview hosts return their standard HTML page for a missing path. If a request for style.css returns text/html and the response starts with the preview site's HTML, the successful status describes the fallback page. The actual stylesheet still needs a reachable URL. A stylesheet in /qa/banner/css/ can also resolve url('../assets/tile.png') from its own directory, which differs from the directory of the HTML page.
Repeat the check with the files you will hand off
Fix the reference in the source directory, then rebuild or repackage the deliverable as usual. Upload that exact output to a clean preview. If you patch files in a preview dashboard and leave the original package unchanged, the next upload can bring the broken path back. Open the new preview with an empty cache. Check that the corrected request returns the expected resource and that the visible banner still matches the approved version.
Exercise the ordinary click target once in the preview. Some designs place the visible creative above a linked element whose position depends on the missing stylesheet. A fixed image can therefore coexist with a click area that has moved. Use the preview's configured destination and avoid any test that sends a real customer event. Record whether the navigation reached the intended page.
Keep an exact record of what passed
Put the preview URL, package version, corrected request path, and destination check in the launch record. Include the original failed path when it helps the next reviewer recognize a regression. The FroggyAds banner launch guide places creative assets and destination checks together in that record. For this particular issue, the useful handoff is the evidence that the approved package works from its real hosted directory with the same assets and click target the reviewer saw.