Skip to:
Content

Opened 9 years ago

Closed 7 years ago

Last modified 7 years ago

#1741 closed enhancement (fixed)

Resolve redundant URLs for SEO reasons

Reported by: Ezd Owned by: boonebgorges
Milestone: 1.6 Priority: major
Severity: normal Version:
Component: Core Keywords: 2nd-opinion has-patch
Cc: Ezd

Description

In the buddybar we got several duplicate content issues which is bad in the world of SEO. This means 2 or more links are pointing to the same content or page which in worst case can be blocked in the SERP's

Please fix the issues below in the "My Account" drop-down menu so we get 1 unique url to 1 unique page.

Activity:
Activity link: http://testbp.org/members/ezcali/activity/
Personal link: http://testbp.org/members/ezcali/activity/just-me/

Profile:
Profile link: http://testbp.org/members/ezcali/profile/
Public link: http://testbp.org/members/ezcali/profile/public/

Groups:
Groups link: http://testbp.org/members/ezcali/groups/
My Groups link: http://testbp.org/members/ezcali/groups/my-groups/

Settings:
Settings link: http://testbp.org/members/ezcali/settings/
General link: http://testbp.org/members/ezcali/settings/general/

Use the menu button as a link - Activity, Profile, Groups and Settings link - and remove the 4 sub-menus to solve this.

Attachments (2)

1740.01.patch (2.2 KB) - added by boonebgorges 7 years ago.
1740.02.patch (8.9 KB) - added by boonebgorges 7 years ago.

Download all attachments as: .zip

Change History (21)

#1 @Ezd
9 years ago

  • Cc Ezd added

Note: The issue needs to be fixed inside the Profile as well where you have duplicate content on the button links. (let me know if I should make a new ticket for this as the above primarily concerns buddybar).

#2 @apeatling
9 years ago

  • Milestone changed from 1.2 to 1.3

This is part of a larger issue, it has been this way since 1.0, so I think we can punt and deal with this in 1.3.

#3 @boonebgorges
8 years ago

  • Component set to Core

It works this way because of the way that subnav items are added and their screen functions are loaded. Does anyone have a good idea for how to fix it? You could just do permanent redirects from eg /profile/public to /profile/. But that seems like a hack.

Maybe a better fix would allow dummy subnav items which don't have screen functions attached to them. The items in the buddybar dropdowns would be pointed toward the shorter url, and the profile subnav tabs wouldn't have real screen functions attached to them, as they'd just point to the parent.

#4 @boonebgorges
8 years ago

  • Milestone changed from 1.3 to 1.4
  • Summary changed from Duplicate content in My Account = Not good to Resolve redundant URLs for SEO reasons
  • Type changed from defect to enhancement

#5 @DJPaul
7 years ago

  • Owner set to boonebgorges
  • Severity set to normal
  • Status changed from new to assigned

#6 @DJPaul
7 years ago

Related to #2681

#7 @boonebgorges
7 years ago

Owner set to boonebgorges

Point taken :)

#8 @boonebgorges
7 years ago

  • Keywords has-patch 2nd-opinion added

I've attached a patch with a possible solution. The patch does three things:

1) Redirects example.com/members/boone to the default component (generally example.com/members/boone/activity)
2) Changes bp_core_new_nav_item() so that visitors are redirected to the default_subnav_slug when available. Eg, example.com/members/boone/activity will redirect to example.com/members/boone/activity/just-me
3) Fixes the blogs component so that the subnav tab actually works (this is currently broken)

I like this solution because it removes redundant URLs for profiles in a way that is non-intrusive and backward compatible. Its biggest downside is that the resolved URLs are generally longer and uglier; you will never resolve to example.com/members/boone, for instance.

Thoughts?

#9 @boonebgorges
7 years ago

  • Resolution set to fixed
  • Status changed from assigned to closed

(In [5313]) Force ambiguous item URIs to resolve to their most specific versions, to avoid content duplication. Fixes #1741

#10 @boonebgorges
7 years ago

(In [5412]) Refactors URL canonicalization logic, moving it into the single bp_redirect_canonical() which is loaded from bp_core_load_template() instead of redirecting during the nav setup routine. See #1741. Combines all canonicalization into a single redirect. Fixes #3771. Ensures that query strings are preserved on redirects. Fixes #3777.

#11 @nacin
7 years ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

I would tend to think that canonicalization should roll up. We don't standardize on /some-post/page-1/, we standardize on /some-post/.

Likewise, http://profiles.wordpress.org/users/nacin/profile/ should not redirect to http://profiles.wordpress.org/users/nacin/profile/public/. I'm not particularly familiar with the internal routing of BuddyPress, but the redirect should be in the reverse. /settings/general/ should go to /settings/, not the other way around.

And, assuming /users/nacin/ reflects the public profile, which means that /users/nacin/profile/ or /users/nacin/profile/public/ should redirect to /users/nacin/. "Ambiguous item URIs" are fine because we know what they should be on them. The most specific versions shouldn't be canonical in those cases.

Am I making sense? Am I wrong?

#12 @nacin
7 years ago

bb_redirect_canonical should hook into template_redirect, ideally, not new bp_core_pre_load_template hooks. You may find those difficult to support in the future. Themers may start using them to insert content.

#13 @boonebgorges
7 years ago

  • Keywords has-patch removed

bb_redirect_canonical should hook into template_redirect, ideally, not new bp_core_pre_load_template hooks

This was not possible before, because of our load order. Due to changes made in the past day or two, it should now be possible. See #4031.

I would tend to think that canonicalization should roll up. We don't standardize on /some-post/page-1/, we standardize on /some-post/

I am of two minds. The core team discussed this pretty thoroughly before implementation. On the one hand, there's no question that rolling up means prettier URLs.

On the other hand, there are a couple of considerations in favor of "rolling down".

  • It's done. No more work would be required.
  • The analogy with /page-1/ is not perfect. It seems to me that the difference between /users/nacin/profile/ and /users/nacin/activity/ is more substantive than the difference between /some-post/page-1/ and /some-post/page-2/. The latter is a way of distinguishing between different parts of the same resource; the former is (arguably) about different resources. So, while in the case of pagination I agree 100% percent that you should roll up (pagination does not provide any semantically relevant information about the resource), it's not as obvious that we should, since the additional URL chunks give insight into the fact that it's a different sub-resource of the user.
  • We allow admins to change default nav/subnav, either by defining constants, filtering various values, or using bp_core_new_nav_default(). This means that, on one installation of BP, /users/nacin/ could resolve to the Profile, while on another it could resolve to the user Activity Stream. That means that there would be some conceptual inconsistency between different BP installations.

None of these is a knockdown argument. Rewriting to roll up will not be difficult. It's possible that the additional information provided by the more specific URLs isn't very valuable, and in any case it can be inferred from the <title> tag, navigation states, etc. And different conceptual schemes on different BP instances may be a good thing rather than bad.

Would like the feedback of another core dev before making a final decision about it.

#14 @boonebgorges
7 years ago

  • Keywords has-patch added

John and Paul and I talked about this a bit, and we decided I'd write up a patch for Nacin's suggested change, so that we would be able to test side-by-side. See 1740.02.patch. General approach is the same: during the process of adding menu items based on the requested URL, assemble a 'canonical stack', which is used in bp_canonical_redirect() to determine the canonical URL. The stack is built in such a way that the default component or default subnav is left out, resulting in a canonical URL that rolls up.

Please have a test, comparing against the current trunk. Be sure to test URLs like this:

  • example.com/members/boone/activity/just-me/ (rolls up)
  • example.com/members/boone/activity/mentions/ (doesn't roll even though activity is default component, because of non-default 'mentions' action)
  • example.com/members/boone/ resolves
  • example.com/members/groups/my-groups/ (rolls up)

Same for groups.

So, the question is: does this feel like a more natural way of browsing the site, given what Nacin and I lay out above about rolling up/down? Thanks in advance for feedback.

#15 @DJPaul
7 years ago

Patch has been put onto testbp.org

#16 @DJPaul
7 years ago

Might merit its own ticket, but don't we also need to update the rel='canonical' parameter in the page head?

#17 @boonebgorges
7 years ago

  • Resolution set to fixed
  • Status changed from reopened to closed

(In [5895]) Reconfigures canonical redirection so that URIs canonicalize up (less specific) rather than down (more specific). Fixes #1741

#18 @johnjamesjacoby
7 years ago

(In [5922]) More redundant URL tweaks

  • Do not include sub_nav slug in $link if it's the default for its parent
  • Add missing priorities to bp_screens actions to ensure adding/removing works correctly
  • Avoid double-negative is_object() checks
  • Add phpdoc header to bp-core-buddybar.php
  • Various code clean-up
  • Debug-notice dodging where missing
  • See #1741

#19 @djpaul
7 years ago

(In [5952]) Make canonical redirects 301s, not 302s. See #1741

Note: See TracTickets for help on using tickets.