Your section page tells Google to index a URL that redirects
If a folder page like /blog/ or /shop/ names /blog as its canonical, and /blog redirects back to /blog/, Google is handed a loop. The usual result is that it stops crawling the section entirely.
By Chen Deng · OxOne, Calgary AB
- Time5 min
- You needYour browser
- FindsSections Google never crawls
Open the section page on your site, view source, and find the canonical tag. Paste that exact URL into your browser. If the address bar changes even by one slash, the tag is wrong — edit it to match the URL that actually loads.
We found this on our own site this week, and it had been quietly costing us every new page we published.
Most sites have folder pages: /blog/, /shop/, /services/. On nearly every host, both spellings work — you can type it with a trailing slash or without, and you land in the same place. What is easy to miss is that one of those two spellings is not really a page. It is a redirect to the other one.
Now look at the canonical tag. That is the line in the page source that tells Google “this is the real address of this page, index that one.” If the page that loads at /blog/ declares its canonical as /blog, you have told Google to go index a URL that immediately sends it back to where it started.
| What you see in the source | What the browser lands on | Verdict |
|---|---|---|
canonical = /blog/ | /blog/ | Correct — they match |
canonical = /blog | /blog/ | Broken — points at a redirect |
canonical = /blog/index.html | /blog/ | Broken — same fault, different spelling |
canonical = http://… | https://… | Broken — the redirect is the protocol |
What Google does about it
Not much, and that is the problem. It does not show you an error. In Search Console the section simply sits under Discovered — currently not indexed, and if you open the URL inspection detail, the last crawl date reads never. Google found the address, decided it was not worth fetching, and moved on. Everything filed underneath that section inherits the same fate, because the section page is how Google walks down into it.
On our site two whole sections were in this state. Every article we had published into them was live, correct and completely unfetched.
The two-minute check
- Open your section page — whatever loads when you click “Blog” or “Shop” in your own menu.
- Right-click, View Page Source, and search the text for
canonical. - Copy the URL out of that tag and paste it into a fresh browser tab.
- Watch the address bar after it loads. If it changed at all — a slash appeared, a slash vanished,
index.htmldropped off — the tag is pointing at a redirect.
The fix is to make the canonical tag say exactly what the address bar says. One character. Then do the same for the og:url tag beside it, and for the entry in your sitemap, which usually copied the same wrong spelling.
Why nobody catches this
Because the tools people use to check say the page is fine. Most link checkers ask the server a HEAD request — “are you there?” without downloading anything — and a lot of hosts, Cloudflare Pages included, do not apply their redirect rules to HEAD. So the checker gets a clean 200 and reports no problem, while Googlebot, which asks with a normal GET, gets the redirect.
If you check redirects from a terminal, this is the difference between curl -I yoursite.com/blog, which will lie to you, and curl -s -o /dev/null -w "%{http_code}" yoursite.com/blog, which will not.
Your sitemap, where a redirecting URL spends crawl budget to be told to go elsewhere, and your own menu links, where every hop is one more fetch before Google reaches the real page. Both are the same one-character edit.
Every one of these came out of work we actually did. If you would rather not do it yourself, book a free 30-minute diagnostic and we will tell you which of these your business is losing money to.