7,740 pages with redirect: what Search Console showed at Bauerntüte

The question came with a screenshot from Search Console: 7,740 pages with redirect, and was that Linkjet? Linkjet is our redirect plugin, and we use it ourselves on the website of Bauerntüte. Bauerntüte is an organic food delivery service from Cologne with a WooCommerce shop on the theme Enfold and several hundred pages and posts. Since August 2026 we have been looking after search, loading speed and conversion there.

A number of that size feels like an error. Before changing anything, we wanted to know where it came from.

What the “Page with redirect” report means

In the indexing report of Search Console, “Page with redirect” lists URLs that Google requested and that redirect to another URL. Google then indexes the target, not the old URL. That is normal for any website that has been around for a few years: products get renamed, categories merged, typos in links caught.

The report only gets interesting with three questions. Who redirects? Where to? And do your own links or the sitemap still point to the old URLs?

First, the timeline

Search Console shows the history of the report. The value jumped from around 5,600 to 7,100 on 13 July 2026 and to 7,500 on 24 July. Linkjet only arrived on the site on 6 August. In August the number rose by about 300 more, which matches the redirects we had created ourselves while merging duplicate pages.

So the direction was clear: most of it was older than our plugin. Who had caused it only became visible in the next step.

Who redirects: the X-Redirect-By header

WordPress writes a header into the response for its own redirects that names the trigger. Many plugins do the same. Requesting the headers is enough:

curl -I "https://example.com/old-url/"

HTTP/1.1 301 Moved Permanently
Location: https://example.com/new-url/
X-Redirect-By: WordPress

WordPress sets WordPress there, Yoast sets Yoast SEO, Linkjet sets Linkjet. If the line is missing, the redirect usually comes from the server or from a plugin that does not identify itself.

We exported 500 example URLs from the report, assigned 407 of them clearly to a group and requested the headers for 60. The result:

In the sample of 60 URLs, Linkjet redirected 41 times, WordPress 19 times, Yoast not once. For the total there is a hard upper limit: Linkjet had 558 rules at that point. Even if every one of them is in the report, that is 7 percent of the 7,740 at most.

A small detail: if you type /kiwi/ and land on the right page, that is not Linkjet's doing. Linkjet only redirects on an exactly matching rule. The guessing is done by the WordPress core with the function redirect_guess_404_permalink, which looks for a similar post for an unknown URL.

The biggest share: Enfold's sorting form

On shop categories and brand pages, Enfold adds a form that lets visitors choose sorting and the number of products. Every choice creates its own URL with parameters, like this:

/produkt-kategorie/gesamtsortiment/?avia_extended_shop_select=yes
    &product_count=24&product_order=asc&paged=1

The paged=1 at the end is redundant, because page 1 is the category itself. WordPress therefore removes it with a redirect. Googlebot follows the form variants, finds thousands of combinations, and every one of them ends up in the report. At Bauerntüte this has demonstrably been going on for years. On top of that came URLs with the parameter wpam_id from an affiliate plugin that is no longer even installed.

These URLs have no value of their own for Google. We therefore excluded them from crawling via robots.txt. In WordPress the file is virtual, and you can extend it with the robots_txt filter:

add_filter( 'robots_txt', function ( $output ) {
	return $output . "Disallow: /*avia_extended_shop_select=
Disallow: /*wpam_id=
";
} );

The categories themselves stay reachable and indexable, only the sorting variants are no longer crawled. A word of caution: a Disallow prevents crawling, not indexing. For URLs that were never in the index, that is enough. If such URLs are already indexed, they need a noindex, and Google can only read that if it is allowed to crawl.

What we found in our own rules

Linkjet was not the cause of the big number. Going through all rules, we still found two problems, and we had created both ourselves.

The first: a script we had used to catch orphaned URLs had a fallback for URLs without a suitable target, the shop's overview page. 237 rules pointed there. Among them were URLs that never had any content: /cgi-bin, /api/graphql, /signin, /vendor and similar paths that automated scanners probe on every website. They sent bots into the shop. Google may treat many redirects to a single generic target as soft 404s, as pages that effectively no longer exist. We deleted 30 such rules, and those paths answer with a 404 again. The remaining fallback rules cover old blog and shop URLs that used to have real content. We are now looking for a better target for each of them individually.

The second: 14 rules pointed to targets that redirect themselves, for example to a product that was later renamed. Such chains cost an extra hop on every request. We pointed each rule directly at the final target.

Neither shows up as an error in any Search Console report. You only find them by going through your own rules line by line and opening every target once.

Why the number will go up again

A second report was connected to the first. At the beginning of October, “Crawled - currently not indexed” listed 1,573 URLs, almost all of them feeds: /tag/…/feed/, /category/…/feed/, /produkt/…/feed/. WordPress creates a separate feed for many archives and even for individual products. For a shop, hardly any of them is useful.

We redirected these secondary feeds to their parent page and left the main blog feed alone. The effect looks paradoxical at first: on the next crawl the feeds disappear from “Crawled - currently not indexed” and show up again under “Page with redirect”. So the number we started with goes up. That is exactly what should happen, because now the crawler lands on a page with content.

What you can take away for your own website

• Read the history before you act. A jump on a specific day usually matches a change on exactly that day: a new plugin, a theme update, a change in the shop.
• Ask the headers. curl -I and the line X-Redirect-By tell you within seconds who triggers a redirect. Ten samples per group are enough for a clear picture.
• Check your theme for parameter URLs. Sorting and filter forms create countless variants. Whatever has no value of its own does not belong in the crawl.
• Do not redirect in bulk to a catch-all target. Every old URL should point to its best replacement. At Bauerntüte, old pages about delivery for offices, such as /lieferservice-fuer-firmen-und-bueros/, now lead to the page about Firmenobst, fruit deliveries for offices. If there is no suitable replacement, a 404 is more honest than the shop or the home page.
• Merge duplicate posts. Two posts on the same topic compete with each other in search. At Bauerntüte, for example, there are two texts about capers. The shorter one is to point via 301 to the detailed guide Kapern: Herkunft, Sorten und Verwendung (in German), so the signals add up in one place.
• Keep chains short. With every new redirect, check whether its target redirects itself. Linkjet reports chains, other plugins often do not show them.
• Look at your own links. Internal links and the sitemap should point to the final target, never to a URL that redirects first.

How to set up redirects in WordPress properly is covered in How to Set Up a 301 Redirect in WordPress. If you are comparing tools, see 7 Best Free WordPress Redirect Plugins Compared (2026).

What this case study does not show

We counted, assigned and cleaned up. What this means for Bauerntüte's rankings we have not measured, so we do not claim anything about it. Search Console reports change with every crawl, and Google does not visit every URL equally often. The figures above come from the analysis in September and the state in October 2026.

While cleaning up, the 404 log led us to a second, bigger problem: crawlers that used the shop's sorting links to put products into carts hundreds of thousands of times. The full story is in 616,000 add-to-cart requests in eight days: the cart trap.

Frequently asked questions