Those individual machine IP addresses are for identifying the computers to each other and to the server inside your network (called the LAN or Local Area Network). The IP address you need to block in Google Analytics is the one that connects the LAN to the outside internet. Unless your network has an unusual setup, using the browser of any computer or device connecting to the network (including phones using WiFi) to type "what is my IP" into the address bar will return the same IP address for the all the machines inside the network. (Large companies occasionally have multiple outside connections, but it doesn't sound like that's what you're dealing with.)

In addition, most commercial internet connections use static IP addresses so the IP "shouldn't" change, but anytime major changes or outages occur, it's a good idea to doublecheck the IP address to be sure it's stayed the same.

Make sense?

Paul

Sidenote: this is one of the main security purposes of a router. It routes all those internal machines' connections out to the internet through a single IP address, so the nasties out on the internet don't have access to an IP address for an individual machine that they can use to direct attacks against it. Thus the network admin only has to protect one device from direct attack from the nastyweb - the router - instead of having to protect every machine individually.

SO here's the scoop...  Between here and the MozCon Facebook Group we've got a number of folks interested, so we're going to grab a table together for lunch on Tuesday at the conference. I'll try to mark it with something noticeable, or you can tweet me @thompsonpaul and I'll let you know where to find us. Hope to see lots of us there!

In addition to the possibility Cat mentions, it's also possible someone has configured Indeed.com as an additional search engine in GA's Admin settings (Property > Tracking Info > Organic Search Sources - see screenshot next comment) As far as fixing the past data, you can't "change" it, but you could use a custom segment which filters it?

Let us know what you find!

Paul

(Tried to include screenshot, but Moz keeps barfing on submit.)

The answer is that it actually depends very much on exactly what kind of coding is used to accomplish the effect, Ron.

In most cases, this kind of slider effect is accomplished using some variation of JavaScript. While Google has said it is "trying" to have it's crawlers recognize text from scripts, it almost never works that way.

So it won't be flagged as "hidden" text, because in fact Google won't even consider it to exist on the page.

An easy way to test is to view the source for the page in question - you'll see that none of the words of text actually exist on the page in any form, even in the code.

For the ultimate example of this - go into Google Webmaster Tools and use the Fetch as Googlebot tool to fetch the page. Then you'll see exactly the content that googlebot will see. It won't see the text, therefor it can't index and rank it. Ergo no SEO benefit at all.

Where you could get into trouble is if you did have text on the page designed to make googlebot think the page is about one thing, while using this kind of scripted text to try to show the visitor something completely different and unrelated. Google could then suspect you of cloaking and penalize accordingly. (Cloaking is when you intentionally show googlebot one thing and the user something different for nefarious purposes)

But if you're adding the text as a usability enhancement for your visitors in a way that googlebot doesn't happen to understand, you won't get any SEO benefit from it, but you also shouldn't be penalized for it.

Paul

Just came across a terrific resource that reminded me you'd asked about further reading, Ben.

Check out BrowserDiet for a huge collection of resources about tuning front-end performance of websites. (You'll see #6 talks about exactly your original question)

I can also recommend reading Steve Souder's two books - High Performance Websites and Even Faster Websites - both from O'Reilly. Souders is pretty much the leading specialist in this area. He's the creator of YSlow, one of the primary tools for measuring/analyzing site speed, and is now Head Performance Engineer at Google. His website is SteveSouders.com

That'll be more than enough to get you started. Lemme know if you're still hungry for more!

Paul

P.S. The report details from tests at webpagetest.org can also teach you a huge amount, and there's a forum there run by Patrick Meenan (who built webpagetest) which is just excellent. Patrick frequently answers questions personally.

The approach you're using is correct and no, you're not really adding an extra step. That's not how canonical works.

A canonical is not a redirect like a 301. It's just an instruction (suggestion actually) to ignore the URL variables when determining the URL of the page. It will have zero effect on the transmission of the ranking authority through the 301-redirect.

The challenge you will have though, is if you create your own UTM tag to generate the source of the visit as being from the old domain1's 301 redirect, it's going to overwrite ALL the other source/medium info from the original site's visit. So domain2's Analytics isn't going to record the source of the original site1 visit as social, organic, referral etc. All redirected visits will get whatever source/medium you designated in your UTM tag.

It may be possible to programmatically catch the original traffic source on domain1 and programmatically write the UTM tags to include it in the 301, but I wouldn't know how to suggest trying to go about it.

Paul

The version with URL entities you posted is almost right, Seamus, but there's a a weird combination of entities around the "hyphen surrounded by two underscores". For some reason, this is showing as %E2%80%93 when it should just be a - (There's no need to encode a hyphen as it's a standard URL character)

Try this as the source URL, with the redirect set as NOT a regular expression:

/blog/Inside_Flowers/post/Online_Marketing_for_Florists_Part_1-_A_Website_You_Won%27t_Regret/

I've tested that and it's working on my test install. If it doesn't work for you, there may be an encoding issue on your Windows server that's different from what I see on Linux/Apache.

Lemme know if that works?

Paul

P.S. Here's the Source URL for the second example used in the WordPress Forum post:

/_blog/Inside_Flowers/post/Valentine%27s_Day_Statistics_2013/

I'm with Anthony that this is a perfect example of where there's no reason to guess when testing can give you your visitors' answer instead of your own.

I suspect testing will show that a form on the homepage isn't going to get used much. Filling out a contact form is a fairly deep-funnel conversion. A visitor must already be pretty sure they're considering doing business with you to bother filling out the form. Or they've looked through the site and can't find the info they're looking for.

Are they likely to make this decision based on just having seen your homepage? Not likely. Better to use that space to give a new visitor more useful info.

But that's just my opinion. Test and let your visitors tell you whether they'll use it

Paul

Ollie, if I'm understanding your question correctly, the easiest place for you to start is with Google Webmaster Tools. You're looking to discover URLs of pages that used to exist on the sites, but no longer do, yes?

If you click on the Health link in left sidebar, then click Crawl Errors, you get a page showing different kinds of errors the Google crawler has detected. Click on the Not Found error box and you'll get a complete list of all the pages Google is aware of that can no longer be found on your site (i.e. 404s).

You can then download the whole list as a CSV and start cleaning them up from there.

This list will basically include pages that have been linked to at one time or another from other sites on the web, so while not exhaustive, it will show the ones that are most likely to still be getting traffic. For really high-value incoming links, you might even want to contact the linking site and see if you can get them to relink to the correct new page.

Alternatively, if you can access the sites' server logs, they will record all the incoming 404s with their associated URLs as well and you can get a dump from the log files to begin creating your work list. I just find it's usually easier to get access to Webmaster Tools than to get at a clients server log files.

Is that what you're looking for?

Paul

The trick with sitespeed testing, Brett, is that you need to approximate as closely as possible the experience a real user will have.

By far the best tool for this in my experience is webpagetest.org.

It uses actual browser rendering for it's test, not a synthetic imitation. it also allows a couple of other critical customizations:

• select which browser you want to test your site with (you'll be surprised at the differences! Use you Google Analytics to tell you which browser majority of your visitors use)
• Select what sort of connection speed to test from (eg slower DSL which will also mimic phone users or faster cable connection)
• select a specific city to test from (this will have major effect - e.g. you should test from the San Jose location which is much more realistic for your Comox location than an east coast or southern US test would be)
• run a mobile-specific test
• shows both first load and repeat visit (particularly tests caching effectiveness)
• provides a waterfall view so you can exactly which elements may be causing issues

The app also provides full Google Page Speed results/recommendations and a number of other trouble-shooting tools.

GTMetrix provides a number of these, but doesn't have the same flexibility/customization available, I've found. (Though it is using a Vancouver-based server for your test from here (Alberta) which is useful.)

Note that you will get different results each time though, if you're using a real-life tool. That's due to differences in network load and latency and even different load on your server each time tested.

Finally, below is a screenshot demonstrating why you absolutely need to use a real-life test, not just synthetic Page Speed or YSlow scores - the site has a beautiful synthetic score yet a disastrous load time (due to server issues)

Paul

rDQjD.jpg

Sorry, one additional - since you mentioned using Open Site Explorer...

Go to the Top Pages tab in OSE and filter the results to include only incoming links. One of the columns in that report is HTTP Status. It will tell you if the linked page's status is 404. Again, just download the full CSV, sort the resulting spreadsheet by the Status column and you'll be able to generate a list of URLs that no longer have pages associated with them to start fixing.

Paul

You're right to be confused, B. The terminology is unfortunate and misleading.

To answer your questions

1. Yes

2. Yes.

A disallow in robots.txt does nothing to remove already-indexed pages. That's not its purpose. Its only purpose is to tell the search crawlers not to waste their time crawling those pages. Even if pages have been blocked in robots, they will remain in the index if already there. Even if never crawled, and blocked in robots.txt, they can still end up indexed if some other indexed page links to them and the crawlers find those pages by following links. Again, nothing in a robots.txt disallow tells the engines to remove a page from the index, just not to waste time crawling it.

Put another way, the robots.txt disallow directive only disallows crawling - it says nothing about what to do if the page gets into the index in other ways.

The meta-robots no-index tag however explicitly states to the crawler "if you arrive at this page, do not add it to the index. If it is already in the index, remove it".

And yea - as you suspected - if pages are blocked in robots.txt, the crawler obeys and doesn't visit those pages So it can't discover the no-index command to drop them from the index. Thus the only way a page could get dropped is if a crawler followed a link from an external site and discovered the page that way. A very inefficient way of trying to get all those pages out of the index.

Bottom line - robots.txt is never the correct tool to deal with duplicate content issues. It's sole purpose is to keep the crawlers from wasting time on unimportant pages so they can spend more time finding (and therefore indexing) more important pages.

The three tools for dealing with duplicate content are meta-robots no-index tags in a page header, 301 redirects, and canonical tags. Which one to use depends on the architecture of your site, your intended purpose, and the site's technical limitations.

Hope that makes sense?

Paul

Yup - Chris has the solution. The robots.txt disallow directive simply instructs the crawler not to crawl, it doesn't have any instructions regarding removing URLs from the index. I'm betting there are other pages linking in to the subdomains that the bots are following to find and index as the URL Removal requests are expiring.

Do note though that when you add the no-index meta-robots tag, you're going to need to remove the robots.txt disallow directive. Otherwise the crawlers won't make any attempt to crawl all the pages and so won't even discover most of the no-index requests.

Paul

[Edited to add - there's no reason you can't implement the no-index meta-tags and then also again request removal via the Webmaster Tools removal tool. Kind of a "belt & suspenders approach. The removal request will get it out quicker, and the meta-no-index will do the job of keeping it out. Remember to do this in Bing Webmaster Tools as well.]