.NET Postbacks are BAD for SEO

antic

antic

Perch
(No, BAD isn't an acronym)

Just in case anyone doesn't know.. I just found this out... Google cannot index pages which use Microsoft's "postback" infrastructure. Aw gee, it was such a good idea, too. :rolleyes:

Search engine spiders just can't do postbacks. Avoid em for pubic sites that need to be indexed.

Search Engine Optimization (SEO) and ASP.NET Developers

Just FYI. I'd never thought about it before now, but I feel vindicated... I hate them and I hate viewstate... die viewstate die! But for coding in general, I love .NET. You just gotta use it right.
 
it makes sense really, as postbacks don't display X information until X action happens, and spiders simply can't, and likley won't do this in the near future. I'd imagine as more "ajax" hits which is really just fancy postbacks, that they will work to make "ajax ready" search engines, but on the other hand it will require developers to to something like "alt text" for their Ajax sites in the long term as well.
 
I don't like the idea of Google pandering to M$ - should be the other way around. :)

Postbacks are a crappy idea to begin with. Goes against all the normal standards (as usual) to have every page being a form submission, and a javascript-controlled one at that.

And of course M$ has hijacked the whole "ajax" thing. It was never about postbacks, it used to be simply using hidden IFRAME's, then it used the XMLHTTP browser object, and then M$ made it all postback-driven which just sucks.

I never use .NET controls, all my stuff is .NET but I produce standard pages, no postbacks, no viewstate.

I do hope postback doesn't become a standard. It's ok for intranet, inhouse stuff, but not for the web IMO.
 
I?m not sure I follow what you?re saying.

I never use anything but links for navigation, so spiders don?t have any difficulty indexing the site. I would agree that using buttons tied to postback events for navigation is not a good idea, as the links are not exposed for spiders to follow. But I?ve never had a problem using Microsoft's "postback" infrastructure for other various web controls (buttons, etc.). In fact I find it convenient.

As far as ?every page being a form submission, and a javascript-controlled one at that?, the form and postback don?t really play a role on the initial GET. The page is simply rendered when the request is processed, pretty much like any other page, and, therefore, there should not be a problem when spidered. In fact, if you wrote an simple HTML page to accept some user input and respond to an submit button click, you would use a form with some inputs and would most likely want to use some client-side javascript validation to allow or disallow the submit. Isn?t that a form that is javascript-controlled?

Viewstate is pretty convenient too, although I did run into a problem with it recently. But that was on a WebUserControl that was in a WebUserControl that was in a WebUserControl that was on a Page that was part of a MasterPage that was part of a MasterPage. And the application required a ton of client-side editing, with correlated values getting set via javascript. Viewstate kind of got in the way and it got a bit tricky. But for simpler pages Viewstate has saved me a great deal of coding. Thinking back to the days when I would write html and asp in Notepad and would have to get each input?s value on the POST and then reload each one on the Response, I can clearly say that I would never want to go back.

riley
 
I guess I'm referring to .net's predilection to make everything a postback if you use controls for links instead of using normal html links. I've seen many sites which have links that are in fact postbacks because someone added them as web controls.

Some sites use dropdown lists as navigation menus. Google can actually crawl them, if the complete URL for each item is exposed in javascript and easy to read. A postback version of the same thing isn't crawlable, because of the way it's implemented - i.e. if all such variables and string are kept in code, as many coders would naturally do, without thinking of the seo side.

So one has to be very careful when using .net when seo is important. But I do personally hate viewstate and the whole postback thing. When I add up the time spent overcoming problems using webcontrols, and doing it the traditional way, it's exactly the same.

The only time webcontrols have saved me time is for creating full on intranet style web apps - that, IMO, is where it shines. But everyone has different needs... I just don't think "the new way" is always the answer to everything. That being said, I positively love using the IDE etc. Just like my old VB6 days. :)
 
I think we agree on more than you might think.

When creating web pages, I use very few, if any, webcontrols. My rules are as follows: if I don?t have to control something?s content from the codebehind, there is no need to use a webcontrol. Otherwise, if I do need a webcontrol, make sure it has some useable content on the initial GET (i.e., without user intervention). Furthermore, I would NEVER put primary navigation in webcontrols that don?t expose the links to spiders.

So we actually agree on almost everything. Where we disagree is where to place the blame for pages that spiders can?t index, because the links aren?t exposed. To illustrate, I will use a loose analogy (and please take this in the lighthearted way in which it is intended). Suppose you asked someone to screw 2 pieces of wood together and that person, bored with his screwdriver and feeling that his hammer was a much more powerful and sexy tool, pounds the screw into the 2 pieces of wood with that hammer. Although the 2 pieces of wood are stuck together, the result is probably not quite what you were looking for. You say ?That?s not right. I always use a screwdriver for that.? And riley says ?I agree. What kind of fool would do that and expect to get the results we are looking for?? But then you curse Stanley Tools for manufacturing and marketing the hammer. :)

Microsoft supplied some really nice webcontrols in DotNet. But the developer is ultimately responsible for choosing the right tool for the right job. Frankly, I think the most important tool any web developer can use is the ?View Source? menu item on the web browser. If you can?t see something in your rendered content (like links), spiders wont either.

riley
 
You must log in or register to reply here.
Back
Top