Our Ahrefs Domain Rating fell from 23 to 6. The number was hard to ignore. It was also not an explanation.
That distinction shaped the investigation. A third party score can tell you that something changed in its model. It cannot tell you which technical decision caused the change, or whether the same movement appears in search performance. So we treated the drop as a prompt to inspect the site, not as a verdict.
The inspection found a real problem at the root URL. For visitors without an existing language preference, the same URL could return a temporary redirect to different locale paths depending on the request location. That behavior was inconsistent with the permanent locale structure we wanted search engines to understand.
We fixed it. We still cannot honestly say that this redirect caused the Domain Rating drop.
What the score actually tells us
Ahrefs defines Domain Rating as a relative measure of a website's backlink profile on a 0 to 100 scale. The calculation depends on the sites linking to a domain and on the wider Ahrefs index. A score can therefore move even when a site has not lost the same proportion of backlinks.
Ahrefs also states that Domain Rating is not a Google ranking factor. It is useful for comparing backlink profiles and noticing changes, but it is not a direct measurement of how Google ranks a page.
That left us with two separate facts:
- We observed the score fall from 23 to 6.
- Our root redirect behavior needed to be corrected.
The facts existed at the same time. Their timing did not prove that one caused the other.
What the root URL was doing
The old middleware selected a locale from the request country when no locale preference was already present. It then redirected a nonlocalized path such as the root URL to that locale with a 302 response.
In simplified form, the relevant behavior looked like this:
const country = request.cf?.country
|| request.headers.get('CF-IPCountry')
|| 'US'
const targetLocale = LOCALE_MAP[country] || 'en'
return new Response(null, {
status: 302,
headers: { Location: `/${targetLocale}/` },
})
The code was trying to be helpful. A visitor in Germany could be sent to the German locale, while a visitor in the United States could be sent to English.
The problem was the crawler facing contract. One source URL did not have one stable destination. Its response depended on location, and the redirect said the move was temporary.
This matters because Google treats permanent and temporary redirects differently. Its redirect guidance says that permanent redirects such as 301 and 308 are strong signals that the target should become canonical. With temporary redirects such as 302 and 307, the source generally remains the canonical URL in search results.
Temporary redirects are valid when a change really is temporary. They are the wrong default when the site has a permanent locale hierarchy and needs a deterministic canonical entry point.
Why location dependent routing was risky
Imagine two crawlers requesting the same root URL from different locations. One receives a redirect to /en/. The other receives a redirect to /de/. Both responses are temporary.
Nothing in either response tells a stable story about the site's preferred root destination. The behavior can also make external tools record different chains depending on where and when they crawl.
This does not automatically destroy authority, and a 302 is not a penalty. Search engines can interpret redirects using more than the status code alone. The issue was that our implementation mixed three concerns in one response:
- The permanent structure of the site
- The visitor's likely language
- The visitor's saved preference
Those concerns deserve different handling. The canonical route should be stable. Personalization should happen only when there is an explicit preference or after the stable page has loaded.
The deterministic fix
The corrected middleware separates a new request from a returning visitor with a saved locale choice.
For a cookieless request to a nonlocalized path, the server now returns a permanent 301 redirect to the English path. The destination is the same regardless of country:
https://zenovay.com/ -> https://zenovay.com/en/
For a visitor who already has a locale preference cookie, the middleware can still honor that personal choice with a temporary redirect. That is a genuinely user specific response, not a claim about the site's canonical structure.
This is a small code change with a useful property: a crawler and a clean browser now see one predictable first hop. We verified the live root response with ordinary requests, Googlebot requests, and different language headers. Each returned a 301 to the same English URL.
The fix does not require us to remove localized pages. Every locale still has its own URL. Language selectors and saved preferences still serve visitors. The change only makes the default entry path deterministic.
What we can conclude, and what we cannot
We can conclude that the old root redirect was a technical flaw. It used a temporary status for a permanent site structure and allowed the destination to vary by request location. The current behavior is easier for crawlers, external auditing tools, and humans to reason about.
We cannot conclude that the flaw caused the entire Ahrefs score change. We do not have a controlled experiment that isolates the redirect from changes in Ahrefs' index, the backlink graph, referring domains, or other site factors.
We also cannot claim a recovery before the data shows one. Shipping the fix is the start of observation, not the end of the story.
The responsible approach is to record the change date and watch several signals separately:
- Domain Rating and the referring domains behind it
- Newly discovered and lost backlinks
- Search impressions and clicks from first party search data
- Indexing and canonical selection for the root and locale pages
- The redirect response seen from clean requests over time
If those signals improve together after the fix, the evidence becomes more interesting. It still needs cautious interpretation.
A practical redirect audit
You do not need a large SEO platform to catch this class of problem. Start with the HTTP response itself.
- Request the root URL without cookies and record the status and
Locationheader. - Repeat the request with different language headers and, if possible, from different regions.
- Confirm that permanent public routes have one deterministic destination.
- Follow the chain and check that it ends without extra hops or loops.
- Inspect the final page's canonical and alternate language links.
- Test a returning visitor with an explicit locale preference separately.
- Save the result and the deployment date so later metric changes have context.
A useful command line check is deliberately boring:
curl -I https://example.com/
Then vary only one input at a time. Add an Accept-Language header. Use a clean cookie jar. Run the request from another region. If the public URL is supposed to have a single canonical destination, the first hop should not become a geography lottery.
The broader lesson
Metric drops create pressure for a quick story. A quick story is often where a technical observation becomes an unsupported causal claim.
The better sequence is slower and more useful:
- Confirm what the metric measures.
- Inspect the system for concrete defects.
- Fix defects because they are defects.
- Separate verified behavior from hypotheses about impact.
- Watch primary and third party signals after the change.
Our Domain Rating drop led us to a real redirect problem. Correcting that problem gave the site a stable canonical entry path. Whether it explains the score movement remains an open question, and we would rather leave that question open than manufacture certainty.
That is the kind of debugging record we trust: exact about the code, careful about causation, and clear about what to measure next.
Top comments (0)