Use javasript event only instead of href for avatars

(Spooky) #1

I think it will be more beneficial SEO wise that the avatars will be linked without href to prevent page rank for linking to unindexed user pages. This links show an overlay anyways, so it’s better to use only javascript with a span tag rather than a link.

What do you guys think?

(Jeff Atwood) #2

Not a bad idea, but I only support it if the change is very easy this close to a 1.6 release.

(Spooky) #3

I think it can’t get easier than that. If you have an event that runs on the link or on the image, you don’t need the ‘a’ tag at at all and you can change the ‘a’ tag to ‘span’ and remove the href attribute. We just need to see that that doesn’t change anything in the style, but I think that’s about it.

If the event has a selector for the ‘a’ tag, we need to chacge it to span, but if not, and the selector is of a class, we don’t need to change the selector.

Too much juice is passed to this pages that are not even indexed, and with many users avatars on the home page, a big waste of page rank is lost.

Update: we should also change it in topics, because there is an ‘a’ tag without href, again, there is not need for an ‘a’ tag there and we can change it to span. We can add cursor:pointer in the CSS so we have a pointer whenever a mouse is on the span tag.

(Spooky) #4

OK, I changed the A to span in chrome and it does trigger the user overlay, so there should be no problem. also for the avatar links in the topic , the ones on the left side.

Regarding the small avatars in the box in the topic, I am checking now.

(Spooky) #5

OK, everything works. We just meed to change from ‘a’ to ‘span’ for all avatars and remove the href attribute if exists.

(Spooky) #6

I think that the class that the event is bind on is called “trigger-user-card” and it reads the data from the attribute “data-user-card”, that’s why the change is very easy.

(Spooky) #7

in app/assets/javascripts/discourse/templates/post/poster-avatar.raw.hbs:

<a href="{{post.usernameUrl}}" classNames="trigger-user-card {{classNames}}" data-user-card="{{post.username}}">{{avatar post imageSize="large"}}</a>

<span classNames="trigger-user-card {{classNames}}" data-user-card="{{post.username}}">{{avatar post imageSize="large"}}</span>

In app/assets/javascripts/discourse/widgets/post.js.es6:

return h('a', {
	    className: `trigger-user-card ${attrs.className || ''}`,
	    attributes: {  href: attrs.url, 'data-user-card': attrs.username }

return h('span', {
	    className: `trigger-user-card ${attrs.className || ''}`,
	    attributes: {  'data-user-card': attrs.username }

That’s what I found while searching for the class ‘trigger-user-card’ in the repository.

What do you think, is it ok the changes?

(Spooky) #8

One more think, I think this one need to be change as well:

in test/javascripts/widgets/post-test.js.es6

   assert.ok(this.$('.who-liked').length === 1);
	      assert.ok(this.$('.who-liked a.trigger-user-card').length === 1);

	      assert.ok(this.$('.who-liked').length === 0);
	      assert.ok(this.$('.who-liked a.trigger-user-card').length === 0);


  assert.ok(this.$('.who-liked').length === 1);
    	      assert.ok(this.$('.who-liked span.trigger-user-card').length === 1);

    	      assert.ok(this.$('.who-liked').length === 0);
    	      assert.ok(this.$('.who-liked span.trigger-user-card').length === 0);

(Sam Saffron) #9

I am not sure, but we may be indexing some higher tl users so keeping an a tag for them may be beneficial

(Spooky) #10

The cons outweight the pros, for most users who use this platform. It’s a huge waste of page rank.

I highly recommend to consider this. I will badly hurt the SEO effort for many users that use the platform. I have 10 years of experience in SEO, I do this for all of my websites. Again, your call, but I do recommend it.

It’s also very important for companies and individuals that fight for ranking up in search results. It’s harder for forums anyway because the page rank is split through a lot of pages (topics), so with user links, it will be just terrible.

It’s so important, so maybe you should consider add an option for that, to prevent linking to user pages. A good option and let the admin decide. Trust me, those who understand SEO will appreciate it a lot!

(Sam Saffron) #11

hmm, the change you just made was to the app view, not the crawler view. The crawler sees the javascript off view.

This proposed change will not change that. Breaking links to the user there is undesirable so instead we should simply add no follow on the links to users in html view.

(Spooky) #12

nofollow doesn’t prevent leak, the page rank is lost. There is no need for nofollow the internal links. What do you suggest, there must be a way to change the a to span no? You know the code better than me.

Or what you are saying that it doesn’t matter, that the crawler won’t see the links anyways?

Let me do a check, a sec.

(Spooky) #13

OK, I understand. I disabled the javascipt and the crawler is not aware of those links because avatars are not rendered in the crawler view. I need to learn the system better.

(Jeff Atwood) #14

Thanks for contributing the code, though, that’s always appreciated :+1:

(Sam Saffron) #15

Yeah really nothing much to do here.

We could add a nofollow to crawler view but it would be a no-op since robots.txt already disallows /users

(Spooky) #16

From what I’ve seen the avatar links are not visible to the crawler, am I right? If that’s so, there is no reason to do anything. I thought that the links are visible to the crawler. FYI, Nofollow should only be used for external links, not internal.

(Spooky) #17

Thanks, I am doing my best to contribute from the spare time I have. I love your software and I want to help make it the best out there. Thanks @codinghorror for being patient with me. Trust me, I really want to help.

(Sam Saffron) #18

It does not matter even if they were… cause