Resolve redundant URLs for SEO reasons

[Ezd]

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.

[Ezd]

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).

[apeatling]

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.

[boonebgorges]

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.

[DJPaul]

Related to #2681

[boonebgorges]

Owner set to boonebgorges

Point taken :)

[boonebgorges]

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?

[boonebgorges]

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

[boonebgorges]

(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.

[nacin]

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?

[nacin]

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.

[boonebgorges]

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.

[boonebgorges]

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.

[DJPaul]

Patch has been put onto testbp.org

[DJPaul]

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

[boonebgorges]

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

[johnjamesjacoby]

(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

[djpaul]

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