Technical SEO case study: discovery files and homepage redirects
A redacted case study by LIPAI WANG: diagnosing and repairing discovery-file responses and a broken homepage redirect.
This case study documents technical work by LIPAI WANG. Website names, domains, ownership details and identifying examples are withheld. The two cases are labeled A and B; they are not presented as named client endorsements.
The problems
Case A concerned discovery URLs that returned ordinary webpage HTML instead of the expected files. Case B concerned a homepage redirect that led visitors to a missing page even though the destination homepage itself worked.
Both findings show why a release should be tested through the actual public URLs. A source change or a successful response code alone does not establish that the intended content is available.
Case A: discovery-file responses
The review compared each endpoint's status, media type and body with its intended purpose. A successful HTML response at a robots or sitemap URL did not satisfy that check.
The repair aligned the deployed discovery files with the intended public site, corrected sitemap formatting and checked the homepage's canonical URL. Post-release HTTP checks confirmed plain-text robots content, an XML sitemap with the expected namespace, and the intended canonical signal.
These results establish technical availability. They do not establish that a search engine has fetched, indexed or ranked the pages.
Case B: a broken entry path
Following the redirect chain showed that the entry URL, rather than the destination homepage, needed repair. A malformed destination sent visitors to a missing page. Testing only a nested content URL had missed the homepage-specific failure.
The repair corrected host routing while preserving paths and query parameters. Verification covered the root URL, the root with a query parameter, a nested content path and the final rendered homepage.
The immediate outcome was a functioning entry path. The underlying application implementation still requires separate regression coverage; the routing repair alone does not prove the cause of every possible redirect failure.
The reusable method
- Record the expected response for each important URL: status, destination, media type and meaningful body content.
- Compare the live deployment with the intended source before changing it.
- Test root and nested redirects independently, including query preservation.
- Verify the public response after release, then open the primary journey in a browser.
- Keep implementation results separate from acquisition results.
Results and limits
The discovery responses and homepage routing were repaired and verified. No search-ranking, AI-citation, traffic, conversion or revenue lift has been measured for these changes. Detailed site identifiers and operational evidence remain private.
For a related delivery example, read the redacted service pricing case study. RankPropel's audit scope describes how this verification method fits into a defined project.