Finding backlinks that point at error pages and redirects

A client has collected mentions over years, and some of them point at addresses that no longer exist in that form: the product page from the old shop, the landing page of an expired campaign. The server answers 404, or it pushes the visitor to the home page across two intermediate stops. Nobody notices. That is exactly why it stays as it is, because in the backlink report the profile looks as strong as ever, while the strength arrives at addresses that cannot rank, because they answer with an error, carry a noindex or only end up somewhere after a detour.

How to go about it in JMX

1. Store the access. Under Settings → Google → DataForSEO enter the login and API password — the one from the DataForSEO dashboard, not the one for the web login. The link metrics have a daily limit of their own.
2. Crawl completely. The query works on the crawl’s inventory. What was not crawled is not queried.
3. Fetch link metrics. In the Link metrics view you set the scope on the left: all internal addresses of the crawl, ordered by click depth, with a limit, and including the redirects, error pages and non-indexable pages, because that is exactly where the finding is. Queries go in blocks of 1,000 addresses, one call per metric per block; each of the four metrics can be deselected. The estimate from addresses, requests and price sits in front of the button.
4. Switch to “Flagged only”. On the right, the notices that the provider alone cannot know arise from the metrics and the crawl:
   • backlinks to an error page
   • backlinks to a redirect
   • backlinks to a non-indexable page
   • internally under-linked
   • high spam score, from 50 out of 100
5. Separate out the internally under-linked pages. Those rows need no redirect but internal links. The optional Link score column in the results, the internal PageRank from 0 to 100, shows how far a page that is well linked from outside has been cut off internally.
6. Export and counter-check. The result goes into the project file and, via Export, as CSV or Excel to whoever enters the redirects. Then crawl again and read the comparison with the previous run in the History tab.

What to watch out for

“Backlinks to a redirect” is not an error but a review item. A single 301 to a fitting target is fine and stays fine. What needs checking are the chains and the 302s. Just as important: empty cells mean “not queried” or “not delivered”, never zero. Read them as zero and you take a page without data for a page without backlinks.

The limit of the method sits in the second step. A URL deleted three years ago, that nothing internal links to any more and that appears in no sitemap, does not turn up in the crawl and consequently not in this table either — although it is precisely that URL carrying the backlinks this is about. That is what the Migration view is for: the old inventory can be collected there from crawl, sitemap, Search Console, a site: query and the Wayback Machine. The archive inventory is capped at 50,000 URLs, and the cap is stated on the result.

JMX writes no redirect file out of the link metrics. Finished .htaccess, nginx .conf or web.config files come out of the environment comparison and out of the migration check. The numbers themselves are paid snapshots: a new run replaces the result list and the findings but leaves the link metrics standing and puts a red bar above them — fetched before the current crawl.

A link somebody placed three years ago, nobody places a second time. What you do not collect now is gone as soon as the referring page itself disappears.