homepage Welcome to WebmasterWorld Guest from 54.161.247.22
register, free tools, login, search, pro membership, help, library, announcements, recent posts, open posts,
Become a Pro Member

Home / Forums Index / Google / Google SEO News and Discussion
Forum Library, Charter, Moderators: Robert Charlton & aakk9999 & brotherhood of lan & goodroi

Google SEO News and Discussion Forum

    
Could old MS FrontPage code remnants hurt Google rankings?
cmendla




msg:4608019
 4:31 am on Sep 7, 2013 (gmt 0)

I suppose that the answer is yes.. I was looking at some of my sites that weren't performing well after I converted them from frontpage to Joomla. Pageviews dropped like a rock. Part of the problem was that the way I had the hosting set up caused the load times to go from less than 400ms to about 4000ms.

One of the issues is that I didn't finish cleaning up the sites after the conversion. My bad on that.

However I started to look at the files and the code. Some of the older sites had a lot of garbage from being copied from word or perhaps frontpage itself. (Spans, font declarations every line etc)

I also noticed that there were still _vti folders all over the place. I"m not sure if they are hurting anything but I"m on a search and destroy with them.

I was looking at the HTML for one of the pages and saw something like

<p><!--webbot bot="Include"
U-Include="../widgets/GoogleforBottomofthepages.htm" TAG="BODY" startspan --></p>
<p>&nbsp;</p>
<!--webbot bot="Include" i-checksum="52832" endspan --></div>
<p align="center">&nbsp;</p>
<p align="center">&nbsp;</p>


The webbot of course was from frontpage. Apparently that never got stripped out when I migrated to Joomla.


Questions:

1. How much does having all the crud in the html hurt things?

2. Does anyone know how serious it was to have left the vti folders?

3. WOuld the code above cause much of a problem. It is possible that google could see that as some sort of black hat stuff.

I'd appreciate any thoughts on this.

thanks

chris

 

CaptainSalad2




msg:4608070
 12:38 pm on Sep 7, 2013 (gmt 0)

>>>1. How much does having all the crud in the html hurt things?<<<

I wish I could say clean code works best but the sites at the top of searches I watch have awful awful code, some have no code at all and frame other sites completely, some donít use any page text and just use an image sunk into the background of the page. Google for whatever reason loves these bulky terribly coded sites, from what I see anyway!

cmendla




msg:4608076
 2:12 pm on Sep 7, 2013 (gmt 0)

CaptainSalad2 - I have a couple of sites like that so I'll try cleaning one up to see if that has any effect... You are right though, it is amazing what gets to the top of the serps sometimes.

EditorialGuy




msg:4608078
 2:26 pm on Sep 7, 2013 (gmt 0)

As has been said many times, "correlation isn't causation." I know plenty of bloggers who aren't happy with their Google Search rankings. Their blogs are published with WordPress. Should those bloggers assume that Google has a prejudice against WordPress?

Try to look at the question from Google's point of view. The mission of Google Search is to deliver the best possible search results to users. So which is more important: the quality and relevance of what users see on the page, or the neatness of the underlying code?

(For what it's worth, our site still has quite a few archived pages that were created with FrontPage back in the day and haven't been cleaned up or converted to our newer CSS-based format. Some of those pages continue to rank well and attract loads of traffic from Google.)

CaptainSalad2




msg:4608083
 2:35 pm on Sep 7, 2013 (gmt 0)

>>>users see on the page, or the neatness of the underlying code?<<<

Since undying coding errors can prevent the site from rendering properly across various browsers it would be a better user experience if some sort of coding standard was implemented and thus rewarded from google. (neatness of code, also speeds up download speed, another positive user experience)

Ive seen sites render fine in chrome but be unreadable in IE. The best way to be sure the browser render the page properly in all browsers is to follow W3C coding standards IMO

EditorialGuy




msg:4608084
 2:54 pm on Sep 7, 2013 (gmt 0)

CaptainSalad2: Sure, it's nice to have clean code and pages that render correctly. But the OP asked (among other things): "It is possible that google could see that [old FrontPage code] as some sort of black hat stuff." That's a whole different issue than whether pages are rendering correctly, and I doubt if Matt Cutts & Co. spend their time devising filters to whack pages that were designed with FrontPage back in the day.

CaptainSalad2




msg:4608092
 3:26 pm on Sep 7, 2013 (gmt 0)

No I agree with you, they pay zero attention to good/bad code, I personally think they should but that's just my opinion!

superclown2




msg:4608174
 10:55 pm on Sep 7, 2013 (gmt 0)

Never mind Google, have you thought about site security? The main reason why MS dropped Frontpage was because of security issues.

cmendla




msg:4608200
 2:15 am on Sep 8, 2013 (gmt 0)

superclown2 - Agreed about the security.. I still have the FP server extensions running on the servers where some of the sites are running... I'm not sure that they are active for a joomla site but you are absolutely correct about cleaning that up.

I thought the situation was a lot worse than it was as I was seeing a lot of frontpage code when I was looking directly at the table through phpmyadmin.. Then it dawned on me to check if it was a published article. It was actually a trashed article. I'm going to see how to purge those trashed articles from joomla.

Kendo




msg:4608207
 4:36 am on Sep 8, 2013 (gmt 0)

Does anyone know how serious it was to have left the vti folders?


Not an issue. In the first place VTI folders are not accessible from the web... they used by the server for indexing.

Secondly, you are talking about MS Frontpage and a lot of designers still use Frontpage on their sites. We use it on most of ours because it has superior management tools and functions*.

While HTML code created by early versions of Frontpage may not be 100% compliant with the WC3 guidelines of today, I doubt if the use if ID numbers for tables, bgcolor instead of CSS style, etc., will affect your rankings.

We no longer use MS Frontpage (circa 2000) for editing and instead use Microsoft Sharepoint Designer which is robust and much more sophisticated editor. In fact it has some quirks that you need to check if you are using CSS styles as it has a mind of its own. Otherwise it is most recommended, but for experienced HTML coders.

* unless you have used the hyperlink and error reporting tools available with Frontpage, you haven't even seen the tip of this iceberg and the power of its editor.

SmallP




msg:4608286
 12:41 pm on Sep 8, 2013 (gmt 0)

I don't think you need to worry. The old Frontpage version of my site did much better than the polished-up brand-spanking-new and compliant Drupal version. The old Frontpage site used "includes" all over the place, but I did clean up the html on each page.

If you've still got Frontpage "includes" on your Joomla site, and the page that they were supposed to be pulling in no longer exists, they are just effectively extra purposeless html on the page. The only way that I see that they could cause a problem is if the page that they are supposed to be pulling in (in the case above that would be ./widgets/GoogleforBottomofthepages.htm) still existed and was dodgy.

EditorialGuy




msg:4608318
 3:03 pm on Sep 8, 2013 (gmt 0)

I don't want to get too far off topic here, but if it's any consolation, you don't need the FrontPage server extensions to make use of most FP features. I've been using FrontPage since 1996 and Expression Web (FP's successor) since it came out, and I got rid of the FP server extensions years ago for security reasons. (Microsoft currently discourages use of the FP server extensions, calling them an "old technology.")

Kendo




msg:4608447
 8:44 am on Sep 9, 2013 (gmt 0)

you don't need the FrontPage server extensions to make use of most FP features


Ah... but the biggest plus with FP is that you can do everything live on the server. You don't have to upload and by working live it means that you can can edit from any computer and not worry about if you or the other guy has the latest file update.

File extensions are required to be able to edit live. Otherwise you have to upload via FTP and that is less productive, just like the alternatives.

EditorialGuy




msg:4608541
 7:09 pm on Sep 9, 2013 (gmt 0)

I wouldn't dream of editing live on the server (I like having what's on the server as a backup), but to each his own.

I use Expression Web (FP's successor) for its editing and organizational tools. Uploading images, pages, etc. by ftp is an ingrained habit, and the only time it's even mildly annoying is when I'm uploading thousands of modified pages from a slew of different directories.

bumpski




msg:4608543
 7:50 pm on Sep 9, 2013 (gmt 0)

I also noticed that there were still _vti folders all over the place. I"m not sure if they are hurting anything but I"m on a search and destroy with them.
Does anyone know how serious it was to have left the vti folders?

Not an issue. In the first place VTI folders are not accessible from the web... they used by the server for indexing.


If you've just copied Frontpage subdirectories like _vti. They contain files named identically to the HTML source code files. Frontpage installed the code block below in your .htaccess file. This and only this blocked google from indexing all these files stored in the _vti directory (that and no links to them). If Google is indexing these files you could have duplicate content issues. Google is sneaky. If you looked at these files with your browser and then went to Google, Google may crawl them.

# -FrontPage-
IndexIgnore .htaccess */.?* *~ *# */HEADER* */README* */_vti*


From Apache
IndexIgnore: Adds to the list of files to hide when listing a directory

If your .htaccess does not have this directive then you should tweak the directive and add it, or as you said, remove all the Frontpage related subdirectorys. There are many!
Remember these _vti files contained great information like the original creation date of the HTML source code file. These dates could be important in Copyright related issues. Frontpage was (is) a very nice, correctly implemented, tool that has been lambasted to no end. It was fabulous in the days of dial up.

Hoople




msg:4608876
 4:48 am on Sep 11, 2013 (gmt 0)

I'm a bit past midway in cleaning up a site from the previous WYSIWYG webmasters. One long scrolly page (code only 240kb) dropped >85% in size. After applying CSS to replace font, big, small etc. that page only experienced a slight loading (speed) decrease. Search performance change undetectable after change. I don't even bother cleaning up small stub pages (low visits/month) - work time vs value just isn't there IMHO.

Besides the OP's point one major FP artifact I encountered was un-scaled images referenced in a huge (~31mb) page with markup being used to scale them down. One image I replaced was a 1.7 mb image; it's replacement was a scaled image of 23kb. To me that's *THE* big evil of Front Page.

Sadly the last FP version (2003) injects less meta-junk but doesn't clean up after previous versions (more work for us?)

Kendo




msg:4608887
 7:16 am on Sep 11, 2013 (gmt 0)

Sadly the last FP version (2003) injects less meta-junk


I don't get any of this using Sharepoint Designer. All pages use header, footer, menu and panel includes as .asp (not the usual FP style include "page") while keeping individual tags for title, description, etc.

Nothings gets added, but I do keep an eye on it.

bumpski




msg:4609366
 7:15 pm on Sep 12, 2013 (gmt 0)

Besides the OP's point one major FP artifact I encountered was un-scaled images referenced in a huge (~31mb) page with markup being used to scale them down. One image I replaced was a 1.7 mb image; it's replacement was a scaled image of 23kb. To me that's *THE* big evil of Front Page.


Hopefully all modern web development tools offer a "resample" button, just as Frontpage did. One reason to scale an image (versus re-sample) might be to offer it in full definition on one page and provide a much smaller scaled version for preview elsewhere. This could make a site appear more responsive. FP also offered auto thumbnail on top of this.

So yes old tools can definitely hurt rankings, just like modern tools, if they are apparently misused.

EditorialGuy




msg:4609370
 7:32 pm on Sep 12, 2013 (gmt 0)

One image I replaced was a 1.7 mb image; it's replacement was a scaled image of 23kb. To me that's *THE* big evil of Front Page.


It wasn't FrontPage's fault that somebody scaled down a 1.7-Mb image. People were doing that sort of thing with manual HTML coding, and they're still doing it in the WordPress era.

Garbage in, garbage out.

Kendo




msg:4618651
 5:16 pm on Oct 23, 2013 (gmt 0)

Garbage in, garbage out.


To help a friend launch a book I offered to create a one page website and asked for some notes about the book for summary, etc. Well what I received was a MS Publisher file detailing quite a few pages including calendar et all.

Now this file could be exported to web pages but they couldn't be edited later so they were uploaded as is. Not only could they not be edited but even if they could, how can one find the real HTML in all the code that is added by Publisher... 95% of the code on every page was style-sheet gibberish (hundreds of lines).

Global Options:
 top home search open messages active posts  
 

Home / Forums Index / Google / Google SEO News and Discussion
rss feed

All trademarks and copyrights held by respective owners. Member comments are owned by the poster.
Home ¦ Free Tools ¦ Terms of Service ¦ Privacy Policy ¦ Report Problem ¦ About ¦ Library ¦ Newsletter
WebmasterWorld is a Developer Shed Community owned by Jim Boykin.
© Webmaster World 1996-2014 all rights reserved