Welcome to the Q&A Forum

You absolutely want to do address this on the new site, not the old one - it's the only way you'll be able to fully transfer the ranking authority form the old site to new.

Since the old home page is almost certainly the strongest on the old site, you may want to consider redirecting it to the new home page, with some referrer-triggered dynamic explanatory text. This could then link to the "about the buyout" page you mentioned for more info. This way, the ranking authority is transferring to a critically important page on the new site, instead of just helping to rank the non-essential about buyout page itself.

Ideally, you're going to want to redirect the pages from the old site to the equivalent URLs on the new one as well. That will provide significantly better authority transfer that just redirecting all pages of the old site to new home page/about buyout page. In which case the same referrer-triggered dynamic content or a header bar can be utilised effectively for those pages as well.

Make sense?

Paul

Valery, you're definitely going to want to normalize your URLs to lowercase. This is a quirk of IIS that it actually respects case in URLs and will consider different case URLs as different pages.

In addition to the search engine problems it creates, it's also a major problem for usabilty - yours and your users. For example, a user who is trying to type in a direct URL can get a 404 error depending on what case they use.

More importantly, your Google Analytics will report on each of those version as separate pages, unless you write a normalizing filter into your GA profiles. Better to do that normalization for the actual site, not just your analytics

While rel=canonical can resolve a number of issues, I've always found it vastly better to correct the actual problem at its root, rather than rely on canonicalization as a catch-all. Anecdotally, I've found correcting issues like this with rewrites seems to allow affected pages to rank better than when just corrected with canonicalization. WIsh I could find time to do an actual case-study on that

Managing rewrites on IIS servers will require a plugin like asapi-rewrite as IIS doesn't handle it natively.

P.S. IIS will also allow and respect spaces in URLs. Users in Internet Explorer will see them as normal with spaces but browsers like Firefox will insert the html entity for a space (%20) into each necessary spot in the URL. This is again a mess for usability, so much better to force rewrite of all URLs to replace spaces with dashes when creating new pages. Many CMSs have plugins for this or you can also use sitewide rewrites to do it after the fact.

There was a Moz blog post published last year that gives a complete rundown of the Whiteboard Fridays production methods. Includes lighting, sound, editing, camera choice etc.

That should give you a great headstart.

Paul

Yea, I figured from some of the commentary and what I saw in his code he must have been acting on some of the suggestions right away. Just didn't want to assume, just in case

And yea, getting to the next level of performance may mean bigger changes like removing some items from the page altogether.

Paul

I think Bryan means has the client linked their Adwords Account to their Analytics account, Vital?

That's the only way this data can be available.

Paul

You're on the right track, allb83, It's critical to be able to segment your Adwords-generated traffic from the rest of your organic traffic in order to fully understand and adjust the value you're getting from your Adwords spend. To accomplish this, you need to have Adwords automatically tag your ads with tracking parameters, .

By far the easiest way to do this (and to get significant additional advantages) is to link your Adwords account to your Analytics account. This will create the needed tagging automatically, and also provide some additional analytics data back into your Adwords account.

Here's Google's own instructions for how to do this: https://support.google.com/adwords/answer/1704341?hl=en

Once complete (and after waiting about 24 hrs for the new data to propagate) you'll be able to easily segment out your Paid Search data within Analytics. Do note through that this won't be retroactive - it'll only apply to new traffic you receive after the linking process is complete.

Not sure why the other responders are talking about Webmaster Tools as this has nothing to do with what you're trying to accomplish.

Hope that's what you are looking for?

Paul

Since you say you have no other subdomains on the site you want to include in the campaign, you will want to specify the www version.

The non-www version could be showing different stats for a number of reasons. Perhaps the SEOMoz crawler first crawled it before the redirect was put in place? Those kinds of updates aren't' instantaneous and not really anything to worry about. You'll likely find they eventually even out.

Just make certain that the htaccess redirect is working as expected and is using a 301 not a 302. (use a header checker to be certain)

Paul

Unfortunately, Moz hasn't done a very good job of proactively notifying users about this bug and its fix, Chad.

The trick is, you have to complete disconnect the GA account form your campaign, then reconnect it from scratch (as opposed to just reauthorizing it.)

There's a note in the Trending Bugs post (3rd entry down) that explains it.
http://moz.com/community/q/trending-bugs-in-moz-analytics

Note that it may take 24 hrs for the newly-connected data to start to show up again.

Hope that helps?

Paul

Just wondering if these responses helped answer your question, Rick?

If not, what else might you need clarified tht we may be able to help with?

Paul

Links that include named anchors (the #something-inside-page part) behave the same way as URLs with other types of URL parameters (e.g. domain.com?variable=whatever)

So short answer is yes, they'll pass link juice as usual.

BUT these kinds of links are prone to creating duplicate content issues. Search engines will see each as a different URL containing the same content when the links get indexed.. At the very least, make sure you've got rel=canonical implemented on the destination page. That way the SEs will know that the page similarities are intentional and will know to give the link authority to to the real URL without the variables.

Note - this is the same issue we run into when putting links with Google Analytics tracking variables out in the wild (e.g.domain.com/?utm_source=email&utm_medium=display&utm_campaign=whatever) so the same precautions need to be taken.

One of the typical ways a site ends up with a huge number of links, but from a small number of domains, is if they end up with a link in a footer or sidebar - something that appears sitewide/on every page. Or from social media sites. In these cases, the huge number of links probably aren't adding a lot of ranking influence.

That's not to say multiple links from one domain don't have value though. There are plenty of situations where an influential site could be linking to you in different contexts. These, I definitely believe, still pas ranking authority. And remember, the only purpose of links isn't ranking. If they're good links, they'll also be sending actual traffic and eyeballs!

Hope that helps?

Paul

The ability to add a logo to reports or to white-label them is available in the Pro Plus and Elite accounts, Ryan. Not in the straight Pro level, unfortunately and not with free accounts, of course.

If you do have a PRO Plus or PRO Elite, you can upload a logo from your campaign settings page.

Paul

[EDIT: Heh... guess we were answering at the same time]

Unfortunately, this is a known bug, and for some reason, Moz still hasn't put a link to the solution on the same page as the error is reported. (The error has been occurring for users for over 6 months, so this is pretty inexcusable IMO).

Anyway - instead of re-authorising your Google account, you're going to need to completely disconnect it from your Moz campaign, then reconnect and re-authorise it. Your system is essentially storing a broken auth token, and just re-authorising doesn't replace the token. That only happens if you fully disconnect then reconnect the account.

Hope that helps?

Paul

P.S. Here a link to a previous Moz response to the same issue including screenshots for the process if you need them.

The reason the site "looks" to tools like it takes a long time to load is because the Google+ API call and the Facebook Connect call are taking an obscenely long time to negotiate their SSL connections - over 11 seconds.

Fortunately the essential user-visible parts of the page (up to document complete) load quickly so the user experience is fine. Might be worth trying to figure out why the SSL negotiation on those 2 files is getting killed so badly though.

Here's a link to the page load Waterfall View that clearly shows the long purple lines indicating SSL delay for those 2 scripts.

There are a couple ways you can do this, Ahmad, but they both require that you have turned off "Instant Results" in your search preferences.

Click on the small gear icon on the top right of the search results and on the dropdown select Search Settings.

In the second section under Google Instant Predictions, select Never show instant results.

Right below that you will now see an active slider that lets you select up to 100 results per page instead of the default 10.

Once you're done, hit Save at the bottom of the page.

A few tips:

• if you are logged into your Google account when you make these changes, they will "stick" until you go back in and change them.
• if you aren't logged into your Google account, the changes will apply until you close the browser. The next time you open the browser to search, you'll default back to the regular settings.
• if you just want 100 results very occasionally - as long as you have Google Instant turned off, you can leave the number of results per page set at 10 as normal. Then when you want 100 results for a particular search, just add &num=100 to the end of the URL that shows in the address bar after you run the initial search. (you'll need to re-add that manually for each additional search)

Make sense?

Paul

As Michael says, local rank tracking is subject to all the personalisation problems of regular rank tracking. But if you're willing to work within those constraints, BrightLocal's set of local seo tools will do exactly what you're looking for, plus some other really useful local functions. And really affordable, considering the features. (No affiliation, just find it a useful suite of tools)

Hope that helps?

Paul

Ayup - and to accomplish that means being willing/able to do some business analysis, not just site analysis. Which moves into the realm of web marketing optimization, not just SEO. Which is where the real value in this whole process lies IMO

I have this problem all the time in the Chrome toolbar too, genkee. Often, if you click the magnifying glass icon in the toolbar window's top bar, it will force a refresh that loads the page elements, analysis & links tabs with data.

Does that work for you?

Paul

There is a unique ID embedded in your Tag Manager code, Christopher. It's specific and different for each container you create for each site (i.e. each container has a different ID). So the Tag Manager code on your pages is calling rules from your specific container. Nobody else's rules could affect your account unless you let them add their snippet to your site.

Here's an example of the Tag Manager snippet showing the unique ID In this case anonymized to GTM-XXXX:

<noscript><iframe src="//www.googletagmanager.com/ns.html?id=<strong>GTM-XXXX</strong>"<br />height="0" width="0" style="display:none;visibility:hidden"></iframe></noscript>

This is assuming, of course that you've followed the best practices of creating a new container for each website. If you're using cross-domain tracking or rollup reporting, I suppose to might be possible to implement all within one container even for multiple sites.

All that said - there's nothing to stop another website from maliciously adding your Analytics code to their own website (whether through Tag Manager or regular manual methods) to mess up your stats. The way to avoid this (and best practice for any site) is to ensure you have a hostname filter to remove all GA calls except those from your own approved hostnames. This also helps filter out "accidental" cases like where somebody has scraped your page contents including your GA code. You'd be surprised how often this happens.

Paul

Yes James, the search engines will treat http://domainname/brooklyn and http://domainname/brooklyn.html as two separate pages which will compete against each other for rankings and as duplicate content.

The Search Engines go very specifically by each character in a URL. Therefore even http://domainname/brooklyn will be considered a separate page from http://domainname/brooklyn/ (Note the trailing slash at the end.)

ANY character that is different in the URL will denote a separate page, as far as the SEs are concerned.

Paul