Welcome to the Q&A Forum

Thanks for your Answer Jane!

Hi Mark: Thanks very much for your note. I tried something similar the SEO Browser, and it shows you what the search engines see. Very useful. Cheers, Wes.

Hi Thomas, I think your problem is partially duplicate content: https://www.google.co.uk/search?q=%22Once+you%E2%80%99re+approved+for+a+ReebokONE+profile+and+you+sign+up+for+the+commission+program%2C+visitors+can+purchase+products+displayed+on+your%22&oq=%22Once+you%E2%80%99re+approved+for+a+ReebokONE+profile+and+you+sign+up+for+the+commission+program%2C+visitors+can+purchase+products+displayed+on+your%22&aqs=chrome..69i57.1682j0j7&sourceid=chrome&es_sm=119&ie=UTF-8#filter=0&q=%22Once+you%E2%80%99re+approved+for+a+ReebokONE+profile+and+you+sign+up+for+the+commission+program%2C+visitors+can+purchase+products+displayed+on+your%22&safe=off This page is virtually identical to a bunch of others in international subfolders, e.g. http://www.reebok.com/sv-SE/reebokonehome/Landing-Page/, http://www.reebok.com/sv-SE/reebokonehome/ (same page but without /Landing-Page/, http://www.reebok.com/nl-nl/reebokonehome/, etc. It's highly unlikely that Google sees any of these resources as highly valuable on their own, given their duplicated many times. The solution here is pretty simple (in theory) though: the rel="alternative" tag (also referred to as the href lang tag) is meant for the purpose of telling Google that although these pages / subfolders, etc. are duplicates of each other, Version A is meant for the US, Version B for Sweden, Version C for Finland, etc. You can also create, for example, an English and Spanish version of the content for the United States and say: "these two pages are for a US audience but this one is for Spanish queries and this one for English." Here are some resources about the tag: https://support.google.com/webmasters/answer/189077?hl=en http://moz.com/blog/using-the-correct-hreflang-tag-a-new-generator-tool Essentially, Google may be refusing to pick this page up because it's basically already seen it many, many times. Cheers, Jane

Hi Dana i did tell the devs to do as you recommended (CSS divs etc) but they just replied saying they did it through javascript instead, but should be ok since on page load the text is defaulting to show. Do you think that would be ok or inadvisable to use java at all as i have also heard elsewhere ? (there has been a drop in rankings since they did this so i'm thinking not ? All Best Dan

Thank you

Hi Syed, I definitely agree that the second URL looks too spammy - especially because some of those areas of London are nowhere near each other (Hertfordshire is about an hour away from the "City of London" - an area in East London - and the demographics of each area are astoundingly different!). Without having seen the pages live, I would probably 301 the second page with the longer URL to the first page, or break out the services offered in different parts of the area to showcase people working in Hertfordshire, the City, etc. If there was enough original content, you could have a page for different areas. My guess is that there is no difference, however, or that there would not be enough different information to justify regional pages - that the page is for one business targeting multiple areas. If so, go with the redirection option.

Hi there, Echoing William about not wanting to step on another's business, but on-page content creation is virtually indistinguishable from the process of creating internal links, in my opinion as an SEO and as someone with a background in writing / publishing. They're generally worked into copy naturally, then site structure (which should have been covered in the site audit) would cover issues like navigational linking. I worked in the sales section of my former agency for the last year I was there (former SEO consultant for them, now back to freelancing) and we certainly never broke anything down like this. What I did find, however, was that larger clients (think corporate giants) want break-downs of everything cost-wise when proposing work. They want to know what the individual cost of writing pages, removing links, even the cost of a consultant's time to monitor tools on a monthly basis. However, adding invoices for things after the fact was clearly a big no-no. The retainer or full cost was stated up front (e.g. $10,000 per month) and then a breakdown was shown, rather than work beginning and then me saying, "Oh, so it's going to be another $2k for X, Y and Z." I can see something like the cost of rewiring internal links being included in a breakdown like this, but if I were writing a quote for re-working the on-page elements of a website, it would certainly not come with an extra invoice for internal links. $20,000 for an initial phase of work before link dev is understandable if you were on a monthly retainer of $10,000 and a massive amount of initial work was put into the campaign - this is the sort of fee I used to be working with when at an agency. But with that fee came a culture of all-inclusiveness. Everything from site audits to link audits and take-downs, social media audit, 12 - 24 month strategy, staff training, tool access, etc. came included. Short version: I'd not be a fan of including these costs after work has started, rather than the company saying: "This is going to cost you $40,000 over six months" and showing the breakdown of where that money is spent. I also personally find the cost of placing internal links to be a natural part of both the site audit and copywriting, so am confused about why that's separate.

David's right, unfortunately - even in the insurance industry, you see sites pop in and out, beating the big aggregators and private companies for short periods. It doesn't happen very often anymore with the blue-chip terms ([car insurance], [health insurance], etc.) but for the second-tier you can still see examples like this. Google isn't perfect at killing spam yet. Keep in mind that some of the big algo updates regarding links in the past two years have not really been targeting spammers at all: they have been targeting otherwise legitimate businesses (from large corporations to "mom & pop shop" organisations) who've sought to use manipulative link dev tactics. The tactics that a lot of recent manual and algorithmic penalties have focused on are buying into link networks and schemes rather than outright automated, old-fashioned spam. You can still get rankings with blackhat / greyhat tactics and some of those rankings last a surprisingly long time. I am not saying that the sites above are outright spam at all - they are affiliates who'll get burned in the end if their strategies aren't watertight, and they all seem to be owned by QuoteSearcher Ltd. Even the big guys in insurance get burned regularly - I'll stay away from citing actual examples due to past experience with agency-based client work, but big brands would rise and fall all the time during the five years I worked in insurance SEO.

Thanks David & Dana, So far, this appears to be erring towards the simple URL's. To address your comment about moving Dana, this is only quite a small site, but I can see the benefits of looking at it in this way. -Andy

I think that if that pluggin just gives you a schema markup. Why not just to go to schema.org get the local code and place in your page. With that you would avoid a pluggin instalation that you slow page speed just fot a simple code that you can get on web.

Hi Jane, Yeah, a number of our clients are in the leisure and hospitality industries which means many travel bloggers naturally link to them in reviews, lists of places to stay in certain areas etc. Occasionally we need to think up clever ways of encouraging that, but it's a field where those who are pleased with the offering tend to give you, at the least, a mention. This particular client, however, doesn't really fit that bill, but they are in an industry where there's plenty of scope for expert advice, FAQs, guides and so on, so I'm sure we can find good content-led solutions. The content side I'm fine with, but it was more the tech aspect of harnessing cloud-based software. Thanks for your help with this - happy just knowing I'm not missing anything on that front! Kind regards, Nick

Hi Luke, As alrockn says, I would redirect the root domain of the duplicate blog to mainsite.com/blog. With the pages that have no duplicate on the main site, either find the likeliest match or redirect to mainsite.com/blog. When I say likeliest match, I mean that if any pages on the old blog seem a good fit with something on the main site, redirect them there. You may find none that fit any of the existing pages. If so, don't worry - I'd redirect those to the main site's blog. Cheers, Jane

You are welcome! I know the "manual" method often takes the longest, but in reality, it is often the most accurate. Hope this helps!

In terms of getting worthwhile links video is actually a pretty solid way to start. You can get a lot of relevant / industry links utilising them, just make sure they link back to your page and not the video hosting one (which YouTube is notable for).

ok thanks Chiaryn is that the actual name of the moz crawler (to allow in Robots) simply rogerbot ? or any other characters etc ? Also is it not the case that even when blocked by robots.txt G can still crawl/index it once password removed, think i read few comments somewhere on Moz that can still happen somehow ? Please advise asap ? Many Thanks Dan

The SEO of the site is probably fine.  The problem with the site is that it takes one page of content and smears it across dozens of thin content, duplicate content, cookie cutter pages.  The SEO is lipstick on a pig.

Well the good news is, after all that, the development server is now safely behind authentication and the level of traffic to the site has returned to previous levels for the last three weeks. Fingers crossed it won't be going anywhere. It has been a wake-up call for the client though and it's started some useful discussions. Every cloud... Thanks for the support!

So, there are lots of 'ifs' here, but the primary problem I see with your plan is that the CDN will return the content to Googlebot without the request hitting your server so you won't have the option to serve different headers to Googlebot. Remember that every page is the main HTML content (which may be static or dynamically generated for every request), and then a whole bunch of other resources (Javascript and CSS files, images, font files etc.). These other resources are typically static and lend themselves far better to being cached. Are your pages static or dynamic? If they are dynamic then you are possibly not benefitting from them being cached anyway, so you could use the 'vary' header on just these pages, and not on any static resources. This would ensure your static resources are cached by your CDN and give you a lot of the benefit of the CDN, and only the dynamic HTML content is served directly from the server. If most of your pages are static you could still use this approach, but just without the full benefit of the CDN, which sucks. Some of the CDNs are already working on this (see http://www.computerworld.com/s/article/9225343/Akamai_eyes_acceleration_boost_for_mobile_content and http://orcaman.blogspot.co.uk/2013/08/cdn-caching-problems-vary-user-agent.html) to try and find better solutions. I hope some of this helps!

I'd say the answer is: