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)

x86_64
Windows 7
defect
Not set
critical

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: briansmith, Assigned: groovecoder)

Details

(Whiteboard: u=user c=mindtouch p=2 2.2)

Attachments

(1 file)

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
Can you provide some specific search phrases and/or url's that show the browserid search results?
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
Weird. We'll take a look for next sprint.
Whiteboard: u=user c=content p=
Target Milestone: --- → 2.3
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?
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, .."
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
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.
(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.
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=
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.
Whiteboard: u=user c=mindtouch p= → u=user c=mindtouch p=2
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.
(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.
(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: nobody → lcrouch
Craig, here's the patch for the MindTouch skin to draw BrowserID buttons with javascript.
Attachment #595887 - Flags: review?(craigcook.bugz)
(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.
Jean-Yves, do you know if the google bot does javascript?
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.
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.
Depends on: 726162
No longer depends on: 726162
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 on attachment 595887 [details] [diff] [review] Use PE to draw BrowserID buttons Committed (with slight modifications) in r101496
Attachment #595887 - Flags: feedback+
Attachment #595887 - Flags: review?(craigcook.bugz) → review+
Component: Deki Infrastructure → Other
Product: developer.mozilla.org → developer.mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: