WordPress.org

Make WordPress Core

Opened 5 years ago

Last modified 6 months ago

#11856 new defect (bug)

URL for 1st comments page is not canonical

Reported by: sirzooro Owned by: markjaquith
Milestone: Future Release Priority: normal
Severity: normal Version: 3.0
Component: Canonical Keywords: needs-patch 2nd-opinion
Focuses: Cc:

Description

When WP generates URL for comments, it always includes comments page number. It should not do this when URL is for 1st comments page - in this case post URL is sufficient.

WP should also redirect to canonical URL version when someone will try to load URL like site.com/some-post/comment-page-1.

Change History (8)

comment:1 @dd325 years ago

  • Milestone changed from 3.0 to Future Release

Punting to Future Release pending patch.

comment:2 @wojtek.szkutnik5 years ago

  • Keywords gsoc added

comment:3 @hakre5 years ago

Related:

  • #7635 - Threaded Comments
  • #7919 - After leaving new comment, not redirected to proper page with comment paging enabled
  • #7927 - Paged comments should show the LATEST page of comments by default, not the EARLIEST
  • #7942 - Enable pretty permalinks for comment paging
  • #7956 - get_comment_link() should be paged comments aware
  • #8583 - If you're using paged coments, 'first' is selected in the options and wp_list_comments is used, then the comment permalinks on the first page will be broken
  • #8630 - Wrong Paged Comments Logic


comment:4 @hakre5 years ago

  • Keywords gsoc removed

Any chance for a patch? Any feedback from GSOC which is over now?

comment:5 @hakre4 years ago

  • Keywords reporter-feedback added

This report properly is not valid. If there is a theme that seperates comments on a page "on it's own" next to the page "that is post content", then this information is needed.

Probably that sort of canonicalization is something a theme need to take care of.

comment:6 @archon8103 years ago

  • Keywords changed from needs-patch, reporter-feedback to needs-patch reporter-feedback
  • Severity changed from normal to major

Can this be revisited?

/comment-page-1 is extraneous and bad for SEO due to duplicate content for situations where the total number of comments is < 1 page (new replies are automatically redirected to /comment-page-1 instead of the canonical url).

For the case when the total number of comments is > the per-page one, either comment-page-1 or comment-page-LASTNUM is superfluous, depending on the sort order.

http://www.blindfiveyearold.com/wordpress-duplicate-content describes this problem (canonical works well in the latest WP, but search engines may not care about canonical when spidering as evident by an example in the link).

comment:7 @chriscct76 months ago

  • Keywords close 2nd-opinion added; reporter-feedback removed
  • Severity changed from major to normal

This seems to be an invalid concern. I could see a situation where a theme might want to have a distinct page for just comments on page 1. An example would be how Disquis works, where they actually have a unique page for the first page of comments, which only contains the topics and threaded replies, and doesn't contain any of the actual contents of the post. Changing this behavior at this stage would break compatibility with plugins and themes already taking advantage of it. Since there is a good solution already for those who don't want this to happen (htaccess or PHP based redirects) this really isn't all too much of an issue. Asking for 2nd opinion, but recommending close as invalid.

comment:8 @sirzooro6 months ago

  • Keywords close removed

There are two problems here:

  • duplicate content, in default installations and many themes who do not do anything special with comments - so default canonical URL would be appropriate for them;
  • some themes or comment systems like Diquis have special use for "comments page 1", so they depend on current solution.

My proposal is different: change core to force canonical comments page URL by default. Additionally provide way to disable it, e.g. by deregistering some action hook or using new "pre" filter. This way both group of users will be happy by having good default implementation, and having way to disable default if they want to do differently.

Note: See TracTickets for help on using tickets.