We have permalinks for each individual post in the forum in the format /posts/jump/123. These URLs do a 301 redirect to the post in the full article, such as /full-article-url#post123. The landing pages have canonical URLs set to the full article URLs.

I just recently started having the issue of the shortened URLs appearing in Google as opposed to the full page versions. This is obviously an issue for two reasons.

  1. We lose all the breadcrumb information in the SERPS
  2. Multiple short URLs all point to the same destination URL, so we obviously want the one preferred URL in Google

Are my canonicals not set up right? What's going on??

Dani AI

Generated

Short summary of the symptom: short "jump" permalinks are being shown in search results instead of the full article URLs, even though the landing pages include rel="canonical" pointing at the full articles. This can happen when what Google actually discovers and follows (redirect headers, link targets, sitemaps, crawl history) differs from the webmaster’s preferred URL. rel="canonical" is treated as a hint and indexing decisions can still favor the URL that carries the strongest crawl/link signals.

Practical checklist to diagnose the gap (expand on points raised by and ):

  • Confirm the redirect is a single, server-side 301 and that the Location header points to the canonical path (no anchor/fragment). Quick check:

    curl -IL https://example.com/short-permalink
  • Verify the canonical markup actually appears in the HTML served to crawlers:

    curl -L https://example.com/full-article | grep -i 'rel="canonical"'
  • Inspect server logs for which URL Googlebot requests and review sitemaps/feeds for any lingering short links.

Recommended remediation steps

  • If the redirect target includes a fragment, change the Location to the plain canonical URL (fragments are client-side and not useful for indexing).
  • Replace internal links and remove short permalinks from feeds/sitemaps so link equity flows only to the preferred URL.
  • Use Search Console’s URL inspection and submit the canonical pages for re‑crawl and reindexing; monitor the index over several crawl cycles.
  • If important external sites point to short URLs, request updates or ensure a clean, single-step 301 to the canonical URL so signals consolidate.

Caution and expectations: rel="canonical" and 301s usually work, but recovery can take time while Google reprocesses signals. If the issue persists after cleanup and re-crawl, collecting concrete evidence from headers, logs and Search Console will guide the next step.

Recommended Answers

All 11 Replies

Can you send a link/screenshot to the query you are running that displays the pages in question?

search query: site:daniweb.com

Every result on pages 2 thru 10 for me

One thought...

The canonical attribute should be used to specify a preferred version of a page with identical content. See: About rel="canonical", heading "Must the content on a set of pages be similar to the content on the canonical version?"

Could it be that Google is not recognizing the permalink and full article as identical content?

I found a permalink and its full article both in Google's cache. You can see this with the following query:
site:www.daniweb.com/web-development/php/code/387843/php-thumbnailer OR site:http://www.daniweb.com/posts/jump/1671625

Viewing the cached pages (with styles disabled), the HTML body content looks almost identical.

A wild guess...

Is it possible something in the HTML header is causing a problem, the meta description perhaps?

I found a permalink and its full article both in Google's cache.

That's the problem :(

Is it possible something in the HTML header is causing a problem, the meta description perhaps?

I don't think so? I don't know. We're using rel=canonical so I can't see why Google isn't respecting that.

Have you tried pointing the redirects to the final destination URL without the # appended? Generally, search engines don't index URLs with a # so Google may be instead keeping the old URL visible. It's strange for Google not to uphold the 301 redirect, however. Google is notorious for altering search results (Title tags, meta descriptions) beyond the default implemented by the webmaster. I'm assuming this is an attemmpt to control the overall user experience.

By chance, are any of the "jump" URLs listed in a sitemap/rss feed?

Generally, search engines don't index URLs with a #

The pages have rel="canonical" that don't have the # though.

By chance, are any of the "jump" URLs listed in a sitemap/rss feed?

Nope.

The pages have rel="canonical" that don't have the # though.

I believe Google is following the 301 redirect all the way to the point where the browser appends the # at the end of the URL. There is a post online that actually speaks to Googlebot actuallu being a headless browser (Chrome). Why it isn't de-indexing the "jump" URLs and following the canonical tag directive, it a bit of a head scratcher.

How long have those "jump" URLs been alive? If they are brand new, how would Google be able to crawl them?

Why it isn't de-indexing the "jump" URLs and following the canonical tag directive, it a bit of a head scratcher.

Not only should it be following the canonical directive, but from what I understand, when there is a 301 redirect, the final destination is what is supposed to be indexed.

The jump URLs have been alive since our system launched, about 3 weeks ago.

Were the jump URLs linked to from internal links when they were first rolled out? Googlebot must be finding them somewhere to be crawled and indexed, either internal links, external links or Sitemaps/Data Feeds.

This situation is bizarre as I have never seen Google blantantly disregard simple directives. I'm also not surprised to see Bing doing the opposite of Googlebot.

Hi cscgal

The permalinks seem to be disappearing from Google search results. Out of curiosity, did you get to the bottom of this? What was the solution?

first of first i want to says ...no budy knows how to google work...it is first thing..and second is.....

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.