Closed
Bug 724411
Opened 13 years ago
Closed 13 years ago
browserid: Search engine snippits for MDN pages are now "MDN has switched to BrowserID, .."
Categories
(developer.mozilla.org Graveyard :: General, defect)
Tracking
(Not tracked)
VERIFIED
FIXED
2.3
People
(Reporter: briansmith, Assigned: groovecoder)
Details
(Whiteboard: u=user c=mindtouch p=2 2.2)
Attachments
(1 file)
51.34 KB,
patch
|
craigcook
:
review+
craigcook
:
feedback+
|
Details | Diff | Splinter Review |
STR:
Do a Google search with MDN results.
Expected Results:
The snippit for MDN pages should contain some useful information
Actual Results:
The snippit contains "MDN has switched to BrowserID, a safe and simple way to sign in with .."
The BrowserID blurb shouldn't appear in the SERPs
Assignee | ||
Comment 1•13 years ago
|
||
Can you provide some specific search phrases and/or url's that show the browserid search results?
Comment 2•13 years ago
|
||
Got this there: http://www.google.com/search?q=mdn+experimental_inline&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:en-US:unofficial&client=firefox-a
I can't understand how the robot got that, but that's a critical problem.
Severity: normal → critical
Assignee | ||
Comment 3•13 years ago
|
||
Weird. We'll take a look for next sprint.
Whiteboard: u=user c=content p=
Target Milestone: --- → 2.3
Assignee | ||
Comment 4•13 years ago
|
||
teoli, can you share some of your seo/web crawler knowledge here so we can try to find out where the crawler is getting the browserid text?
Assignee | ||
Updated•13 years ago
|
Summary: Search engine snippits for MDN pages are now "MDN has switched to BrowserID, a safe and simple way to sign in with .." → browserid: Search engine snippits for MDN pages are now "MDN has switched to BrowserID, .."
Comment 5•13 years ago
|
||
Copying over from my IRC thinkings-out-loud:
Do we have basic stuff like meta keywords and descriptions in the <head>s of pages? That might help. There's also the Open Graph attributes Facebook looks for when links get posted to walls & etc
Comment 6•13 years ago
|
||
There currently aren't any meta descriptons or keywords because there's not really an easy way to make them relevant to the individual page, they would just be the same keywords and description globally.
But it occurs to me now that it might be possible to extract the first 30 words or so from the article to use as a description, and maybe use tags for keywords if I can get a raw list of tags from MT. I can look into it. Keywords are largely ignored by search engines these days (thanks to heavy abuse by SEO hucksters) and have no impact on rankings, but a description is good to have if it can be individualized to the page.
The bots are finding the Browser ID blurb because it's the first real content in the document, with a heading followed by paragraphs (notice that in some results also show the navbar links in the description). I thought googlebot was supposed to be aware of ARIA roles so it *should* skip right to role="main" and mostly ignore role="banner" and role="navigation", but it's clearly not doing that.
While I'm loathe to harm semantics for the sake of SEO, maybe if we used generic spans in the blurb instead of headings and paragraphs, it might make it seem less like real content so the bots won't pay as much attention to it.
But if we're now inserting the dialog with JS instead of hard-coding it, and especially if it's appended in place onClick instead of onLoad, that blurb won't even be there when the bots come crawling. So that might solve this too.
Comment 7•13 years ago
|
||
(In reply to Craig Cook from comment #6)
> But it occurs to me now that it might be possible to extract the first 30
> words or so from the article to use as a description, and maybe use tags for
> keywords if I can get a raw list of tags from MT.
I prefer that you fix this bug by fixing bug 721171. Then to implement these two ideas (that are great but may have some hidden problems on some pages, so may lead to follow-up bugs) after the Kuma Migration.
Assignee | ||
Comment 8•13 years ago
|
||
So, this bug is to add PE to the browserid signin button on MindTouch like we did on django in bug 721171.
Component: Website → Deki Infrastructure
QA Contact: website → infrastructure
Whiteboard: u=user c=content p= → u=user c=mindtouch p=
Comment 9•13 years ago
|
||
Yep. And the bug is critical as Google is using the bogus description much and much as it crawls our content. We'll need to wait for the next crawl to get the correct description back.
The effect on the ranking is unknown yet, but can't be positive.
Assignee | ||
Updated•13 years ago
|
Whiteboard: u=user c=mindtouch p= → u=user c=mindtouch p=2
Reporter | ||
Comment 10•13 years ago
|
||
I suggest rewriting the HTML to use CSS positioning or something so that the BrowserID blurb is at the bottom, rather than the top, of the page. And/or fix bug 721171.
(In reply to Jean-Yves Perrier [:teoli] from comment #9)
> We'll need to wait for the next crawl to get the correct description back.
I believe you can help expediate that by providing a sitemap, which should be relatively simple to do as a one-time thing.
Reporter | ||
Comment 11•13 years ago
|
||
(In reply to Brian Smith (:bsmith) from comment #10)
> I suggest rewriting the HTML to use CSS positioning or something so that the
> BrowserID blurb is at the bottom, rather than the top, of the page.
I mean, so that it is at the end of the page in DOM order, but at the top of the page visually.
Comment 12•13 years ago
|
||
(In reply to Brian Smith (:bsmith) from comment #11)
> (In reply to Brian Smith (:bsmith) from comment #10)
> > I suggest rewriting the HTML to use CSS positioning or something so that the
> > BrowserID blurb is at the bottom, rather than the top, of the page.
>
> I mean, so that it is at the end of the page in DOM order, but at the top of
> the page visually.
That's the current plan, more or less. We're first going to try writing out the entire element with JavaScript so it simply won't exist at all until it's called for. If that proves too hard, we can certainly embed it at the tail of the document and inject it in place when the button is clicked. Either way, the dialog won't be the first content any more.
Assignee | ||
Updated•13 years ago
|
Assignee: nobody → lcrouch
Assignee | ||
Comment 13•13 years ago
|
||
Craig, here's the patch for the MindTouch skin to draw BrowserID buttons with javascript.
Attachment #595887 -
Flags: review?(craigcook.bugz)
Comment 14•13 years ago
|
||
(In reply to Luke Crouch [:groovecoder] from comment #13)
> Craig, here's the patch for the MindTouch skin to draw BrowserID buttons
> with javascript.
The progressive enhancement works nicely to insert the button, but the info dialog is still being included in the same place, just now it's added by JavaScript instead of hardcoded in the HTML. So I don't think this will solve the search engine problem. Nothing has changes as far as googlebot can see (unless googlebot doesn't do JavaScript but I'm pretty sure it does).
I think we have two options:
1. Do a second ajax call and inject the dialog only when the button is clicked (messy)
2. Just cop out and embed the dialog at the tail of the page (we should still write the button with JS though). But this will mean some changes to the JS that makes it appear, we can't piggyback off the same menu script any more.
I don't think it's worth messing with a second ajax hit for the dialog, we still have the form and button done in a nicely progressive manner. I'll work on the scripting to position a dialog stashed at the end of the DOM, for both Deki and Django.
Assignee | ||
Comment 15•13 years ago
|
||
Jean-Yves, do you know if the google bot does javascript?
Comment 16•13 years ago
|
||
That's a difficult question to answer. It definitively does some Javascript, though.
https://twitter.com/#!/mattcutts/status/131425949597179904 (Matt Cutts is the official voice on the Internet about Googlebot)
But that doesn't mean that your work-around will not work. (Especially as only the description snippet are affected for the moment)
Is your current patch risk-free or very-low-risk? We could try it, while you worked on a more thorough patch and meanwhile check if it is doing any good.
Assignee | ||
Comment 17•13 years ago
|
||
Yeah it's low-risk. It's up on stage9 already and it will push to production on Tuesday.
The other thing we can do is move the content somewhere else on the page, but not might be as easy/quick.
Assignee | ||
Comment 18•13 years ago
|
||
resolving fixed for QA for Tuesday push. if it doesn't fix we'll re-open.
Status: NEW → RESOLVED
Closed: 13 years ago
Keywords: qawanted
Resolution: --- → FIXED
Whiteboard: u=user c=mindtouch p=2 → u=user c=mindtouch p=2 2.2
Comment 19•13 years ago
|
||
Comment on attachment 595887 [details] [diff] [review]
Use PE to draw BrowserID buttons
Committed (with slight modifications) in r101496
Attachment #595887 -
Flags: feedback+
Comment 20•13 years ago
|
||
did a number of searches with MDN results and did not see the browserID blurb
https://www.google.com/#sclient=psy-ab&hl=en&source=hp&q=Javascript+MDN&pbx=1&oq=Javascript+MDN&aq=f&aqi=g4&aql=&gs_sm=3&gs_upl=22764l26035l2l26404l14l8l0l6l6l0l361l960l6.1.0.1l14l0&bav=on.2,or.r_gc.r_pw.,cf.osb&fp=e7710eebb1eed43b&biw=1056&bih=681
Status: RESOLVED → VERIFIED
Keywords: qawanted
Updated•13 years ago
|
Attachment #595887 -
Flags: review?(craigcook.bugz) → review+
Updated•12 years ago
|
Component: Deki Infrastructure → Other
Updated•5 years ago
|
Product: developer.mozilla.org → developer.mozilla.org Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•