Welcome to the Q&A Forum

Agreed. I work at a company that builds search engines for websites (TechCrunch uses our search), and one of our biggest advantages over a product like Google Site Search is we'll crawl your site on demand (we're not a competitor to Google's web search product, obviously, so our on demand recrawls aren't an option for SEO ranking). Google, in its attempt to index the entire internet, cannot recrawl your site as soon as you make website changes, nor can it determine perfect relevance for every page immediately upon crawling. Unfortunately, a lot of times, the answer to "I fixed everything, still hasn't helped," is to wait it out. My recommendation would be keep doing what you are doing and work on good, sustainable SEO, and give Google a bit more time to crawl and index the new pages. It doesn't look like there is anything you are doing that is causing the problem, so I don't have a ton more to offer here.

Good luck!

As I understand it, you are asking about rendering the same content to two different domains that differ entirely in the tld (.au & .nz).

Based on my reading of Google webmaster guidelines, if the only difference is the domain and what country the visitors are from, you should not have any issues so long as you use rel-alternate-hreflang as you described. If you have multiple domains targeting the same users, just be sure to add a rel="canonical" tag.

Google's webmaster guidelines state:

"Websites that provide content for different regions and in different languages sometimes create content that is the same or similar but available on different URLs. This is generally not a problem as long as the content is for different users in different countries. While we strongly recommend that you provide unique content for each different group of users, we understand that this might not always be possible. There is generally no need to "hide" the duplicates by disallowing crawling in a robots.txt file or by using a "noindex" robots meta tag. However, if you're providing the same content to the same users on different URLs (for instance, if both example.de/ and example.com/de/ show German language content for users in Germany), you should pick a preferred version and redirect (or use the rel=canonical link element) appropriately. In addition, you should follow the guidelines on rel-alternate-hreflang to make sure that the correct language or regional URL is served to searchers."

source: https://support.google.com/webmasters/answer/182192?hl=en#3

I'm not a netsec expert or a technical SEO expert, but I'm running SEO for my company and have been looking into this for a while now. The tips I can give you are: add rel="canonical" tags to all the http:// versions of your site pointing to the https:// version. Once you get an SSL certificate, make sure to claim all 4 variations of your URL (http://, http://www., https://, https://www.) in webmaster tools and designate which is canonical (this will just make sure the Googlebot knows which is canonical, you'll still want to add the tag to your site pages). Finally, make sure that if you do decide to switch to HTTPS:// (which I highly recommend - some people, myself included, now instinctively use https:// over http:// and if someone points a link at https:// when you aren't using it, Chrome will display a yellow warning interstitial and a red X over the https:// in the address bar), get an SHA-2 certificate, rather than SHA-1, as Google is sunsetting it in the next year. To the comment on page load speed - Https:// slows page load down, but generally not by a substantial amount (also, there are plenty of other ways to address page load time that can offset the hit, and if you've already done all that, the page load hit won't hurt you, since you're in better shape than everyone else). Also, while Google's incorporation of https:// as a signal so far has not seemed to impact results much, it's a near certainty that, based on Google's current behavior, it will become less of a signal and more of a necessity, and as more websites adopt it, the less the slight page load hit will matter. Websites are essentially required to adopt it sometime in their lifecycle, as growth makes security much more of a concern.

Further reading on SHA-1 and SHA-2:

https://konklone.com/post/why-google-is-hurrying-the-web-to-kill-sha-1

http://googleonlinesecurity.blogspot.com/2014/09/gradually-sunsetting-sha-1.html

It's all going to depend on your CMS, but if you are looking to understand what is being referenced, right click on a page on your site and select view source, the search for meta. The meta property description is what should be there (almost all CMS's allow you to edit this). Your page title should be much shorter, and you shouldn't have multiple pages with the same title. Again, nearly every CMS makes this very easy to edit.

This is one of those things that just takes time. We moved our blog from /blog to a blog. subdomain about 2 months ago and have only recently seen SERPs reflect that. Also, the SERP results got better gradually rather than shifting overnight.

Hi unikey,

I'm not 100% sure on negative SEO impact (would be interested to hear if the assumptions I've made from experience are accurate), but I previously worked for a company that did ~10% of their $75mm annual revenue from affiliates, and we primarily used ShareASale. We never saw a negative SEO impact from the affiliates (and we approved nearly all of them, at least initially), which I am assuming is because ShareASale affiliate links are all nofollow. Since ShareASale's value prop is massively expanding your reach to potential customers through their network, they should have been incentivized to make sure there is no SEO downside to leveraging their platform.

However, while this isn't negative SEO-related, I do have a decent amount of experience with affiliates, so you may be interested. You should be somewhat wary of affiliates, especially when the link you provide has a coupon attached. Some (not all, and definitely not the good ones) will just spin up tons of sites like cheap{{company}}coupons.com to try and capture some of the search traffic that is generated by people seeing a coupon code box on your checkout page. Since the way the affiliate model works is by giving a revshare to the affiliate for acquiring the customer, tracked by a browser cookie, they should only be receiving their cut if they sent the customer to you as the original referrer or sent someone to you who was not already planning on purchasing. Someone searching for {{company}} coupons isn't someone the affiliate sent you. The basic ShareASale policy forbids this, but you need to periodically run some searches for your brand + coupons and make sure no one is violating the policy. Luckily, this only really becomes an issue if you are seeing substantial success with affiliates, but I try and check in on this once a month or so.

For a better summary of the problem and a counterpoint (Don't worry too much about whether affiliate marketing is or isn't a scam, what matters if it works for you. These are just more eloquent summaries of the potential upsides and downsides of affiliates), see:

http://venturebeat.com/2013/08/12/the-big-ugly-affiliate-marketing-scam/

http://venturebeat.com/2013/08/15/affiliate-marketing-not-bad/

For SEO purposes, either structure will work so long as it's clear where in the site navigation the page is, since it will just be making it easier for the site to be crawled. For optimizing for sales, the other commenters are right in that you are getting bogged down in things that aren't going to substantially impact customer behavior. Really the only thing you should be worried about with your URL in terms of conversion is whether you are using SHA-2 (people trying to come to an https:// version of your site will get a warning and no green reassurance in the address bar, and a red warning in the address bar if you aren't using SSL at all) and whether a visitor could look at the URL and have a good idea of what the content of that page is. Beyond that, you're optimizing at the extreme margins.

However, if you really do want to attempt to optimize your URLs to an extreme, it really depends on your site structure. If the entirety of the website is a store, then the /shop/ subdirectory is unnecessary. If you have a store as a part of your website, a subdirectory of /shop/ or /store/ or something like that would be helpful in indicating where in the site the URL is pointing. Similarly, having a product subdirectory makes sense if you have multiple categories of products (in your case, say you had both vitamins and paleo cooking ingredients, each with multiple SKUs within the product category). However, if your store only has 9 SKUs, all of which are vitamins, /products/vitamins is unnecessary for indicating where in the site you are (or, you could use /products/ to direct to a page listing all 9 SKUs, in which case the /products/keyword would ultimately turn into products/nameOfProduct).

If you have a site that has a store with multiple product categories all with multiple SKUs, you could consider /store/products/keyword as a format, although that starts to get a bit long. Have you considered using a store.website.com subdomain?

My URL process is: Is it the best indicator of where in the site navigation the visitor is? In most cases, this should mean it indicates that they are in a store, where in the stores navigation they are, and what item they are looking at (keyword). If that's true, then it's a good URL. Secondary concern is keeping the URL from being too long, aim for the most concise but clear indication of where in your sites navigation the user is. The final piece of the URL string (that indicates the specific page the visitor is on) is where you can add the keyword you care about.