Welcome to the Q&A Forum

Yoast's SEO Plugin wins hands down in my opinion as well.

There's nothing wrong with AllinOneSEO - it offers the basic ability to manually enter meta data for each page/post as necessary, and to create a default meta-data template for those pages you're not going to customize by hand.

Where Yoast's plugin shines is that it will actually help coach you through WHAT you should be entering in those different meta fields, and will help you do an essential analysis of every new piece of content you write in order help you improve it before it's even published. The visual presentation of what your SERP snippet will look like is also invaluable.

Many of these aspects are second-nature for experienced SEOs but provide helpful coaching for those not focusing on it full time. Even though I do SEO extensively, I still find having the tools/prompts right in front of me on every post to very beneficial.

In addition, Yoast's plugin includes several important additional SEO-friendly features (like breadcrumbs,etc) that otherwise require additional plugins. WordPress ALWAYS runs better the fewer plugins you have installed.

Paul

It's definitely a very good, Jodi, and is one the significant benefits of moving to WPEngine. They do a superb job with caching, which speeds up your site, as well as automatically enabling a high-performance Content Delivery Network (CDN).

The biggest benefit to a faster site is for user experience. Your visitors will experience a faster website which is a much more enjoyable experience, encourages them to remain on your site longer and can encourage return visits and increased trust.

Site speed is also one of the factors Google includes in their ranking algorithm. This is only true for a relatively small percentage of the top search queries though, so it likely won't make a significant difference for most sites.

The improved usability of your site is by far the bigger payoff.

Congratulations on the step up!

Paul

P.S, You can also look at site speed by page in Google Analytics under Content > Site Speed. Alternatively, you can use a tool like webpagetest.org to get a very real-world measurement of the speed users in different areas of the country/world will experience on your website.

Here's how I look at it, Zora:

• On-page optimisation is now simply the price of admission. If you want to play effectively in search, good on-page is the foundation of everything else you're going to do. If you've got inadequate on-page optimisation, you're going to automatically compromise the effectiveness of all the off-page work you're doing.
  • For example, good links to a page with confusing meta-data and poorly organised content are not going to bring much value. Plus they'll be a LOT harder to get in the first place.
• Really strong, high-quality, useful content will make it MUCH easier to attract links, whether naturally or through link building.
• 301 redirecting is considered to never pass quite as much "link juice" as a native link pointing directly to the landing page

With these things taken into account, my workflow in your situation would be

1. to ensure the on-page optimisation for the new pages on new site is as strong as you can make it
2. take time to research and write new, strong, linkworthy content for the new site
3. do some solid advance planning and have an outreach plan ready to start trying to attract links to the new content as soon as the new site is up.
4. any time left over, pre-plan further off-site link attraction strategies for the new site.

All this assumes you have an absolutely ROCK-SOLID plan for redirecting the URLs from the existing site to the new site, and a foolproof, tested implementation plan for those redirects (plus a solid strategy for monitoring and adjusting them instantly should any issues be discovered).

Does that make sense?

Paul

Oleg and Maurizio are correct in their assessment, but they've each introduced some confusion in the process.

Here's the rundown:

• Xeon processors are extremely powerful processors specifically designed for servers. Atom processors are budget consumer-level processors designed to be cheap, not fast.

• the motherboard and associated systems of a DELL Poweredge are specifically designed for server use. That is unlikely to be true for an Atom-based system.

• both systems contain the same amount of memory (RAM) - 4 GB. It's quite likely that the RAM in the first server is of a faster type though.

• both systems contain the same amount of usable hard-drive space. In servers with 2 identical hard drives and a RAID setup, the default configuration is always what's referred to as "mirrored" or RAID1. This means both drives contain exactly the same content as each other. So even though the total number of gigabytes is double in the first server compared to the second, the total usable space is the same for each.

  • The reason this RAID1 is highly desirable for a reliable website is that if one drive experiences a hardware failure, the other drive instantly takes over so there's no downtime. There is NO protection from getting hacked in this scenario, as each drive constantly copies itself to the other so both are identical. This means a hack would instantly be copied over to the second drive. Proper backup (eg hack protection) requires a separate backup drive stored on a completely separate server. RAID is NOT a backup method, it simplify allows systems to be more reliable even if a hardware failure occurs (called redundancy)

All this to say the first systems is clearly a superior server, as both Oleg and Maurizio pointed out.

However, I'd also like to say - it's pretty unusual that an individual website would benefit from this heavy a server configuration. Only a heavily database-intensive site getting well over a million visits a year would require this kind of power and associated expense.

Most individual websites are much better served by a VPS (Virtual Private Server) which offers most of the advantage of a dedicated server but with significantly more flexibility and lower cost.

Are you certain a dedicated server is what's needed?

Paul

It's serious enough. I mean, why only fix 3 out of the 4 leaks in your boat? If you're gonna fix 'em, fix 'em all

And it's potentially very serious if the unfixed version is one of the two on the primary domain.

It's a simple extra addition to the IIS redirects.

Do note though! All the 301 redirects should point DIRECTLY to the final primary url. e.g. you don' t want a redirect that goes neatstuff.com -> www.neatstuff.com -> www.neat-stuff.com.

The header checker tool will warn you about this by showing two 301-redirects before finally listing the 200 response.

Paul

I'll just add, Dana, that this major a change to the site will often cause massive ranking fluctuations as the crawlers work through the site and consolidate what's going on.

Small comfort, but a week really isn't long enough for things to have settled out to the "new normal". It's a good idea to keep looking for issues, but I'd also hold my breath for another week or two (or three) to see what happens as the dust settles. I know it goes against the grain to wait & see, but in this case I really think it's warranted.

Good luck, and keep breathing

Paul

I don't think there's any way that an 80 to 90% traffic drop can be attributed to the link juice loss of 301 redirects, Kevin. Did you test and confirm that all of the 301 redirects were actually working correctly when first installed?

The challenge now is that many if not most of those original URLs may have now dropped out of the index, if they weren't redirected correctly (since they'll have been 404ing so long that the search engines will have dropped them from their indexes) . So there may not be anything to actually go back to.

Unfortunately it's really hard to offer any sort of specific information in situations like this without being able to actually look at both the old and new domains.

That chart you're showing is from Google Analytics Landing Pages, where the account has been connected to and is importing from Webmaster Tools.

Google Analytics ALWAYS has a two-day lag for reporting from Webmaster Tools. That is to say, the most recent two days in GA will always show zeros for data coming from Webmaster Tools.

Nothing to be concerned about - though why on earth Google doesn't insert a notation to that effect in the Search Optimization reports is beyond me. You're certainly not the first (nor last) to be panicked by this anomaly.

Paul

[Edited to add - this is also true in Webmaster Tools itself, it's just not as obvious because WMT simply doesn't include the most recent (empty) two days in the chart]

Just to chime in here-the usability argument is so important it should probably even trump the SEO considerations.

Usability is about conversion. It doesn't matter how much traffic you can drive to your website, if the usability sucks and drives visitors away, any traffic would be wasted.

On most of the sites on which I've worked, conversion rate optimization gives vastly better return on investment than just trying to drive more traffic.

But this shouldn't be an argument. This is a perfect example of something that should simply be A/B tested, so that the data from actual users will determine the correct answer. No best practices are going to accurately predict the preferences of users on all types of sites. I've seen examples where pop-ups were actually very effective for business goals, despite the fact that so many people bitch about them.

A fairly quick A/B test of your home page with and without a large pop-up would very quickly tell you whether the process was adding value to the visitor's experience or driving them away.

[But I gotta say, an early 2000's era splash page as the front page of your website sounds like a complete non-starter to me, SEO problems or not.]

Paul

As all 3 of us have said here, Pioneer, there is no issue with setting things up the way you are proposing. Can't make it any clearer than that.

To answer your specific point - /sitemap and /sitemap.xml are categorically NOT seen as the same URL by search engines. They are absolutely considered two different pages. Your statement "...two items with the same url, but different file extensions..." is a non-sequitur. If the URLs have different file extensions, they are by definition NOT the same URL. The file extension (or lack thereof) is an integral part of the URL.

Since 3 different people have given you the same answer and you still don't believe us, why not simply test for yourself?

• Implement the two files as above, then use Google Webmaster Tools to report your XML sitemap location, and confirm that it's finding and recognizing it correctly.
• Then use your browser to go to the URL of the regular sitemap and you'll see that it renders the html version of your sitemap map just fine.

Paul

You can insert the canonical header link using your site's .htaccess file, Bob. I'm sure Hostgator provides access to the htaccess file through ftp (sometimes you have to turn on "show hidden files") or through the file manager built into your cPanel.

Check tip #2 in this recent SEOMoz blog article for specifics:
seomoz.org/blog/htaccess-file-snippets-for-seos

Just remember too - you will want to do the same kind of on-page optimization for the PDF as you do for regular pages.

• Give it a good, descriptive, keyword-appropriate, dash-separated file name. (essential for usability as well, since it will become the title of the icon when saved to someone's desktop)
• Fill out the metadata for the PDF, especially the Title and Description. In Acrobat it's under File -> Properties -> Description tab (to get the meta-description itself, you'll need to click on the Additional Metadata button)

I'd be tempted to build the links to the html page as much as possible as those will directly help ranking, unlike the PDF's inbound links which will have to pass their link juice through the canonical, assuming you're using it. Plus, the visitor will get a preview of the PDF's content and context from the rest of your site which which may increase trust and engender further engagement..

Your comment about links in the PDF got kind of muddled, but you'll definitely want to make certain there are good links and calls to action back to your website within the PDF - preferably on each page. Otherwise there's no clear "next step" for users reading the PDF back to a purchase on your site. Make sure to put Analytics tracking tags on these links so you can assess the value of traffic generated back from the PDF - otherwise the traffic will just appear as Direct in your Analytics.

Hope that all helps;

Paul

Looking at this purely from a technical perspective, Rob... (from EGOL's observations above you have content issues as well)

I think you've misunderstood the biggest challenge to recovering from a heavy Panda hammering with a new site.

When you create a new site for recovery purposes you must completely dissociate it from the original damaged site. By 301-redirecting the old to the new URL, you've simply told Google that the old site (with all it's algorithmic penalties) simply exists at the new URL. So the new site inherits all the de-ranking of the old site.

This is why Panda recovery is so tough - you need to literally start again from scratch with the new site. You can't even easily redirect the human traffic from the old site to the new without risking bringing the "penalties" with them.

And this makes sense from the Search Engine perspective. If they've de-ranked your existing site, it wouldn't make sense to allow you to just point to a new domain and sidestep the penalties. Otherwise, nefarious webmasters would just run manipulative sites as hard as they could until they got penalised, then point to a new domain and pick up where they left off until they got caught again.

Looks to me like you're going to need to completely disconnect the two sites (I'm even paranoid enough to suggest a new Google Analytics account and new hosting/domain registration if you want to go that far) and start a significant content rewrite and new content program.

And that's why Panda/Penguin recovery with a new site is so tough. You have to rebuild from the ground up with no help from your previous site. Google has clearly told you it considers your existing content of little value as a search result. Moving that content to a new domain isn't going to change that opinion. Only new, higher-quality content (as well as new additional authority/ranking factors) will.

Sorry to be such a downer on your first post (welcome to the SEOMoz Clan by the way!) but you have a steep road ahead of you and it would unfair to mislead you otherwise.

Paul

You've pretty much answered all the standard  questions that would lead to a decision, Alex - and the answer is "no".

• Do the existing pages have any rank? Nope
• Any valuable incoming links? Nope
• Does the new site have equivalent or equally relevant content to point to? No again

So you knew exactly the questions to ask, and your instincts were right on. Perfect scenario where the urls should just be left to die.

Technically, this sort of url should return a 410 Gone server response, but that would take some extra coding. Returning 404 Not Found in this instance is pretty common and will do the job.

Hope that helps;

Paul

Yes this is really bad. in fact it's deadly for the ranking of your website. With this setting in place, your website is telling the Search Engines not to make any effort to travel through the rest of the pages of your website, and therefore won't be able to add them their index. In addition, none of the authority value of your home page is being passed along to the other pages of the site. This means very little traffic from organic search.

Some of your other pages may get listed by virtue of having incoming links from other sites, but you are giving yourself a massive handicap by having this setting in place. And there's absolutely no reason I can think of why you'd want to keep it in place.

Sounds to me like a glitch when the site was being set up, and it needs to be corrected pronto.

Paul

<object id="plugin0" style="position: absolute; z-index: 1000;" width="0" height="0" type="application/x-dgnria"><param name="tabId" value="ff-tab-21"> <param name="counter" value="331"></object>

In this case, you'd verify the site with rel=publisher connected to the business's Google + page instead of rel=author.

Unfortunately, rel=publisher won't give you any advantage of a rich snippet in search or the other benefits of rel=author at this point, but most expect that those linkages will be implemented by Google soon. So worth doing now to be right on top of it when does get further implemented by Google

There's no point trying to "fake " a rel=author connection - it won' help your site anyway.

That help?

Paul.

I'm going to suggest a hybrid of a number of the approaches mentioned, Cocoon. And the reason is because you essentially have two different purposes in mind.

The footer links should be thought of as click-generating links for real eyeballs. You want to make it easy if someone like the site you designed to be able to find you as the developer. So it's primary purpose is click-throughs. Design it as the call to action you think will best generate clickthroughs.Making the anchor text a little different on each site can't hurt either.

Being sitewide, and on several different sites, these footer links are prime candidates for Penguin devaluation, so no-follow these. Which isn't a problem because you're designing them for clickthrough, not rank-passing anyway.

Then, see if you can get an editorial link from the website as well. "About" pages can be ideal for this as they usually rank fairly well so can pass some juice. And it makes sense that an About page might talk about the folks who built the site. An added advantage is that About pages don't generally have a huge number of additional links, so there's more juice to pass.

And DEFINITELY try to get reviews from your satisfied clients on Google and Yelp at least. Web designers don't typically show up in local search features, but getting the reviews to help your Google+ Local page to rank as well is still very valuable.

Interested to know what you think of this approach.

Paul

<object id="plugin0" style="position: absolute; z-index: 1000;" width="0" height="0" type="application/x-dgnria"><param name="tabId" value="undefined"> <param name="counter" value="166"></object>

In my experience, this is a "worst of both worlds" situation, Jeepster.

Over-optimised internal linking can definitely cause harm, but well-optimized internal links can't make up for over-optimised externals.

If you think of this from the search engines' perspective, it wouldn't really make sense to allow you to alleviate spammy external tactics by being a "good boy" on your own site. Especially when external incoming links are likely a much more important ranking factor than internal links.

That's my .02.

Paul

You're actually up against a bit of a sticky wicket here, SS. You do need the no-index, no-follow meta tags on each page as Irving mentions.

HOWEVER! If you also add a robots.txt directive not to index the site, the search crawlers will not crawl your pages and therefore will never see the noindex metatag to know to remove the incorrectly-indexed pages from their index.

My recommendation is for a belt & suspenders approach.

• implement the meta no-index, no-follow tags throughout the dev site, but do NOT immediately implement the robots.txt exclusion. Wait a day or two until the pages get recrawled and the bots discover the noindex metatags
• Use the Remove URL tools in both Google and Bing Webmaster Tools to request removal of all the dev pages you are aware have been indexed.
• Then add the exclusion directive to the robots.txt file to keep the crawlers out from then on (leaving the no-index, no-follow tags in place).
• check back in the SERPS periodically to check that no other dev pages have been indexed. IF they have, do another manual removal request.

Does that make sense?

Paul

P.S. As a last measure, run an inbound links check on the dev pages that got indexed to find out which external pages are linking to the dev pages. Get those inbound links removed ASAP so the search engines aren't getting any signals to index the dev site. Last option would be to simply password-protect the directory the dev site is in. A little less convenient, but guaranteed to keep the crawlers out.

In  my opinion, no, you definitely should NOT allow the production server to be indexed while it's in this state. For all intents and purposes it IS your dev server at the moment, and the last thing you want is for the search crawlers to think that what's there will be representative of the quality of your site when it's finished.

My recommendation:

• get the current site out of the SERPs. (Use WordPress setting in Settings -> Read to check the "Discourage from indexing" box. DON'T add a no-index in robots.txt until the pages have all dropped out of the SERPs)
• when the dev site goes into operation, make _certain_right from the start it cannot be crawled (vastly better than trying to fix the problem after it get's accidentally indexed).
• as soon as you have time, build a proper front page and a few content pages on the production site that indicate what the full site will be about, and get some strong basic, well-written content on there that will also remain after the go-live. (keep ALL the rest of the pages of the prod site out of the SERPs with meta no-index tags)
• once you have a the new, stable, basic content up on prod, allow the SEs to start indexing it.

This gets the messy stuff out of the SERPs before it can pollute the index (and gives you a bad reputation with any actual visitors to the site who shouldn't be seeing your tinkering). By getting some real content as soon as possible, even on a very basic template, you'll start giving the SEs a quality idea of what is to come. Wouldn't hurt to start building a few backlinks once the basic content is up on prod - e.g. links from its new social profiles etc.

This way, when the full site goes live, you'll already have some quality visibility in the engines, so it will be quicker to get the rest of the new site crawled and indexed.

Does that make sense?

Paul

P.S. If at all appropriate, use the basic prod content to show why/how they should connect with you on social media, and offer them a chance to sign up for your newsletter notification of when the site goes live. (It's never too early to start trying to get those subscribers!)

The other option available (and worth trying since it's so quick to do)...

See if you can figure out a meta-description that will make it stand out from the huge brands above you, and clearly communicate the unique value proposition of your site compared to the biggies.

For whatever searchers scan far enough down to at least see your result, this is the one way available to you to stand out and earn the click. You could even use a bit of Adwords budget to try split testing the meta-description.

Paul