Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Routing of URL with nothing after the discussion ID #181

Closed
dcsjapan opened this issue Jul 27, 2015 · 7 comments
Closed

Routing of URL with nothing after the discussion ID #181

dcsjapan opened this issue Jul 27, 2015 · 7 comments

Comments

@dcsjapan
Copy link
Contributor

This issue is drawn from the discussion in this thread:

http://discuss.flarum.org/d/377/url-parameters/46

Flarum cannot display a discussion when the requested URL contains no info after the discussion ID. That is, it requires at least some text to hold the place of the title string. For example

http://discuss.flarum.org/d/377/placeholder

will open the same discussion as the first URL given above, but

http://discuss.flarum.org/d/377

will only result in a "Not Found" error message. (esoTalk, by contrast, handles such URLs without issue.)

@franzliedke
Copy link
Contributor

I'd argue it's not a bug. Since these URLs represent dynamic content (and are not actually generated anywhere, except for the first one), the only thing we should do is taking measures to prevent these duplicate pages from finding its way into search engine indices. We can do that by using the rel=canonical meta tag.

It's either that, or just removing the topic subject from the URL.

@dcsjapan
Copy link
Contributor Author

To take the last point first...

I think it's very important to have the topic subject in the URL, for reasons explained in my post #29 of the discussion linked above. To put it briefly: URLs are often copied and pasted for use as links, not only within a site, but to other sites as well. When a link contains nothing but an FQDN and a couple numbers indicating the discussion and post number, it gives viewers no incentive to follow it back to the source. So URLs without the topic subject would be less likely to be clicked, resulting in less traffic to a site.

SEO is all well and good, but optimization for real people is important too!

As for the first part, I think using the rel=canonical meta tag is a good idea. But exactly what value would you put in that tag? It seems to me that the best option would be the minimum necessary amount of information needed for Flarum to locate and display the thread. In other words, a URL with the format:

http://discuss.flarum.org/d/377

But currently, Flarum cannot handle such a URL, even though it contains all the information that Flarum logically needs to display a discussion. This means a user who knows the discussion ID but not the title can't just type in the above to see the thread. He has to type in one or more nonsense characters, which do nothing other than hold the place of the title:

http://discuss.flarum.org/d/377/abc

It's really counterintuitive that this URL should work, while the shorter and more precise URL gives only a 404. Again, this is more about optimizing for real people (RPO?) than anything.

So I would argue that (1) Flarum needs to be able to handle the short URL format with nothing after the discussion ID, and (2) this format is the best choice for use as the value of the rel=canonical meta tag.

@franzliedke
Copy link
Contributor

The point of rel=canonical is to designate the canonical URL - the one we deem the "official" one. So I'd argue it should be the one we use for links etc. We don't need to make up an URL just for search engines.

The fact that other URLs linking to the same page can be made up is just an artifact of the technical implementation, they shouldn't exist, and any harm is averted using the rel=canonical tag.

@tobyzerner
Copy link
Contributor

rel=canonical tag definitely should be http://discuss.flarum.org/d/377/abc

But there's no reason not to support URLs like http://discuss.flarum.org/d/377, without the slug. I would even argue that we should move the slug to the end so URLs are like http://discuss.flarum.org/d/{discussion_id}/{post_number}/abc. This is beneficial because then you can link to a post without including the slug (which can be handy). Also if some service truncates URLs (e.g. older email clients), the important info won't be cut off.

Downside is that all URLs would need to include a post number, like http://discuss.flarum.org/d/377/1/abc

@dcsjapan
Copy link
Contributor Author

I thought about the possibility of moving the post ID after the discussion ID. Given the choice between making the slug optional and making the post ID optional, I'd choose the latter.

Adding the post ID to the URL makes it a URL that requests a specific post. It seems to me it should be possible to request a thread without requesting a specific post...

... Hmm. I'm beginning to see the value of systems that don't rely entirely on argument order, using things like &post= to identify optional arguments. I suppose that sort of thing isn't possible here?

@dcsjapan
Copy link
Contributor Author

Sorry about the double posting, but I needed to collect my thoughts (and do a little research) about the canonical tag. (Turns out it might take more than a little research...)

I understand what you're getting at, but I'm wondering what happens when the thread title gets changed. Does the canonical tag get changed along with it? Wouldn't that cause problems if a search engine ends up with multiple canonical tags for the same content? (Or are search engines smart enough to discard the older version?)

That's why I suggested omitting the title slug from the canonical tag. Not only does that give the minimum necessary info to open a thread, it's also the version that will never ever change.

... But I admit I may not be correctly understanding the purpose and use of the canonical tag.

@tobyzerner
Copy link
Contributor

@dcsjapan Fair point... I assume that the search engines would be smart enough to discard the old version, but that's an assumption.

Anyway, I've implemented support for the slug-less URLs, let's continue SEO discussion here: #189

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants