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

Search engine optimization #189

Closed
tobyzerner opened this issue Jul 28, 2015 · 18 comments
Closed

Search engine optimization #189

tobyzerner opened this issue Jul 28, 2015 · 18 comments

Comments

@tobyzerner
Copy link
Contributor

Flarum renders very basic versions of the discussion list and discussions (within <noscript> tags), which are going to be specifically optimised for search engines. This all takes place in Flarum\Forum\IndexAction and DiscussionAction, which extend Support\ClientAction and use Flarum\Support\ClientView. The actions get data from the Flarum's API and pass it onto content views (discussion.blade.php and index.blade.php). I'm happy to explain more if need be because it can get pretty confusing.

Put simply, the code is a mess. It needs to be rethought and refactored. A few thoughts:

  • We probably want to use or build some kind of library that makes it easier to work with a JSON-API document payload.
  • Similarly, we probably want to use or build some kind of library that will help generate URLs/query strings/etc.

Only after doing this will we be able to effectively optimise the SEO content and do the following:

This was referenced Jul 28, 2015
Closed
@axisdos
Copy link

axisdos commented Jul 28, 2015

Noindex for subpages (Inspired by Yoast SEO for WordPress) to avoid duplicate content. and URL Friendly.

@franzliedke
Copy link
Contributor

@axisdos Noindex isn't needed when we have the rel=canonical tag. :)

@dcsjapan
Copy link
Contributor

Questions of how to handle foreign language/unicode URLs -- such as #194 -- will also have SEO implications. In that regard, unfortunately, I think different regions may prefer different solutions.

@tobyzerner tobyzerner modified the milestone: 1.0 Beta 1 Jul 30, 2015
@neandrake
Copy link

Would this tie into Accessibility at all? I'm not extremely familiar with it, but when structuring the noscript HTML along with the rest of the page, it would be nice if parts of it were identifiable for users with disabilities.

http://www.w3.org/WAI/intro/aria

@tobyzerner tobyzerner removed this from the 1.0 Beta 1 milestone Aug 6, 2015
@franzliedke
Copy link
Contributor

Could this approach be an alternative to the noscript tags?

@tobyzerner
Copy link
Contributor Author

Quite possibly, feels a little bit hacky though? I'm not too fussed

@dcsjapan
Copy link
Contributor

dcsjapan commented Apr 1, 2016

#906 is an SEO-related issue specific to the Tags extension.

(I hope I was right to file it as a separate issue.)

@franzliedke franzliedke modified the milestone: 0.1.0 Apr 7, 2016
@ghost
Copy link

ghost commented Jun 8, 2016

I investigated links on my Flarum and posted results in this topic on official Flarum forum, have a look:
https://discuss.flarum.org/d/3103-is-the-flarum-s-seo-seriously-messed-up-or-am-i-doing-something-wrong

@franzliedke
Copy link
Contributor

For reference: https://webmasters.googleblog.com/2014/02/infinite-scroll-search-friendly.html

@franzliedke
Copy link
Contributor

Also interesting, with regards to changing <title> and other meta tags when doing client-side navigation: http://searchengineland.com/tested-googlebot-crawls-javascript-heres-learned-220157

@tobyzerner tobyzerner removed this from the 0.1.0 milestone Jul 22, 2017
@gwillem
Copy link
Contributor

gwillem commented Nov 23, 2017

@01010000101001100 refers to a bug in the pagination code. Version 0.1.0-beta.7 will infinitely link to the "next" page id, even if there are no more discussions. I have only 1 page of discussions, but Google has already crawled to page 584. Fixing this would probably improve SEO a lot.

(--> #1310)

franzliedke added a commit that referenced this issue Jan 10, 2018
Otherwise, search engines start indexing pages that aren't filled yet.

Refs #189.
@franzliedke
Copy link
Contributor

@gwillem @01010000101001100 Thanks for the heads-up. I've fixed the incorrect generation of pagination links, along with some other minor pagination-related improvements.

@askvortsov1
Copy link
Sponsor Member

To clarify, what exactly needs to be done here? Based off of the link Franz sent, Google seems to be fully capable of handling our frontend. Is it just a question of ensuring pagination is properly done?

I've been resolving meta title and description issues through a series of PRs, see #495 (comment), #2049

@BartVB
Copy link
Sponsor

BartVB commented Mar 4, 2020

Google is able to render Javascript but this is much, much slower than indexing 'static' HTML. More information here:
https://ja.dev/entry/blog/nagayama/render-budget-en

TLDR; use Javascript for endusers, HTML for crawlers.

@franzliedke
Copy link
Contributor

Also, Google isn't the only search engine, especially in some other countries.

@franzliedke
Copy link
Contributor

You're right, though, that we need to spec out more clearly what aspects we want to tackle. "SEO" is a very generic and not very actionable issue title. 😆

@xtrmus
Copy link

xtrmus commented Oct 15, 2020

There are too many dofollow links on the site. ("Mentions, Likes, Replies") - Their attributes must be "rel = nofollow".
This item is very, very important. The reason for this: When Google bots enter the page, they see too many dofollow links and try to index them.

the ?near tag.
Google indexes both the near tag and the normal page. Therefore, because the two urls are trying to index in the same way, the bot is slow and cannot navigate the site in detail.

@askvortsov1
Copy link
Sponsor Member

Splitting into #2397, https://github.com/flarum/core/issues/626, #2397

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

No branches or pull requests

9 participants