Welcome to the Q&A Forum

Hi Philip,

I am not sure I understand this part of your question "does the rating system have to be present and possible to rate?".

You don't need to have anything on the page that enables someone to leave a rating/review in order to use structured markup on those ratings/reviews.

I would recommend using an approach combined with rel-alternate-hreflang to link the various product pages in different languages together.

My approach would be to give the star rating (marked up with http://www.schema.org/AggregateRating) gathered across all reviews for that product (in any language). Then on each different language page I'd show the reviews that are in that language (http://www.schema.org/Review).

I have never handled this exact situation, but that feels like the right way to approach it. What do others think?

-Tom

Hi David,

Google/Bing etc. have very few problems recognising such characters in the Latin alphabet. It looks like you are mainly concerned with umlauts, which Google handles intelligently. For example...

• Google will identify the difference between a search for "Küchen" (kitchens in German) and "Kuchen" (cake in German) and offer up relevant results. This is true in Google US and Google UK, not just localised Googles.

• Search suggestions work just fine with these characters, and even with the standardised way of rewriting them when there is no accessible way to type them (for umlauts this is with an e following the letter). For example, in Google.de, type "Kue" and you will be given the suggestion "Küchen".

You are mainly concerned with brands, which muddies the waters a little because many people in English speaking markets won't bother/know how to type the umlauts. However, Google normally handles this well and recognises the intent.

I would recommend you ensure you consistent use the brand name with the foreign characters, as intended. Google/Bing and co. shouldn't have any problems. Which HTML encoding you use is by the by, in my opinion, as long as the characters are rendering correctly.

For the amount of effort you spend on such a scheme, you could do a lot better by just trying to think outside the box, and thinking more creatively than the others in your niche. When you are forced to think of a solution that is purely white hat that can achieve or outperform a grey/black approach, you often come up with a solution that whilst maybe not so quick is going to be more sustainable and add value to your users.

I encourage you to think about what would be really awesome content/tools/linkbait for your industry, and what hasn't been done or done well (or not been updated for sometime - this is a good one), etc etc. Then do that. You will not be disappointed you bothered.

Hi August,

You've made a small error; it looks like you've used the rel canonical example from here; http://www.seomoz.org/learn-seo/duplicate-content. The "canonical-version-of-page" there is supposed to be an example of a folder on the site and shouldn't be literal, so the code on your page should be:

Where the value inside the 'href' part is the URL to the page you wish to be the canonical version. I hope that makes sense!

What Francisco is suggesting is an alternative, and often preferred, method of handling this scenario, where a user trying to visit the other (non-canonical) versions of this URL would be redirected automatically by their browser to the canonical version. This does have some advantages but I'd say it isn't significant enough for you to worry about.

Best of luck!

From a crawler point of view, I don't believe there is any difference. However, MaryAnneG makes a good point about scrapers. The downside of absolute URLs is they are harder to maintain, especially if you move to a new domain or change the structure of your site.

I would differ slightly in my approach. If you robots.txt block the other sites, then any organic links they build up will be worthless.

Rel canonical across domains should be fine, so put that in place. Then meta noindex, follow: this way the juice flows in at least. Make sure the rel=canonicals go to the same specific page on the duplicate, obviously.

I like your second screenshot with the links to the recent issues that persist over all the pages, and think keeping them separated by year makes them easy to navigate for users and easy to crawl for search engines.

I would comment, whilst you are restructuring, that your content is very deep. It seems everything on your site exists at least 2 folders deep:

/online/en/home.html

Given your site seems to be only available in English I don't see the necessity of the 'online' or the 'en' directories.

Secondly, the publications:

/online/en/home/publications/journals/afp/afpsearch.html

Here having 'publications' and 'journals' seems superfluous, and now a 'home' directory has also appeared. Your content is now 6-7 levels down! I'm unsure of what CMS / software is powering the site, but I'm sure this could be changed. So you could have much cleaner, which is much easier:

/journals/afp/search.html

instead of:

/online/en/home/publications/journals/afp/afpsearch.html

Which I think would be much nicer for users and engines.

Best of luck!

Hi Panos,

I don't necessarily disagree with Eric's answer, but I wanted to answer from a different point of view. I'm going to assume you really want or need some refresh mechanism built into the page.

In which case I'd agree that a Javascript approach using AJAX is probably a better solution. It will mean that users only need to load the new article headlines, and not the whole page, so the strain on your servers should be reduced. Furthermore, I find it a neater solution all around anyway - you could provide a notice 'new headlines available' that people click to refresh the articles list. This might be the best of both worlds?

Either way, meta refresh isn't as flexible, isn't as clean, and will put more strain on your servers.

Good luck!

-Tom

Well, it depends! Use of the rel=canonical tag sounds fine to me, I agree they'll feel more 'at home' with a .de domain.

However, what is the strategy for the German users to find the .de version of the site? I'm guessing AdWords or similar where you display the .de domain to increase the CTR. However, it would be nice to be able to bring users in via the organic rankings.

Seeing as this is a valid problem faced by many, it is a shame the engines haven't yet provided a better way to handle it.

Viel Glück!

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!

Hi,

So it sounds like you have ~20 internal links per page, which is not unreasonable and shouldn't be a point of concern.

However, if you are still worried, then I'd worry less about finding a specific list of links to dig into - at this scale that likely won't be very helpful or actionable.

I'd recommend that you reviewed the "Top Pages" report in OSE to see which pages have a large bulk of links. Then I'd do a review of the internal site architecture looking at the major elements (top and side navigation, footer links, any dynamic menu systems) and see whether there are places just to tighten that up a little. You can use what you learnt from the 'top pages' report to help inform this review.

However, as I said - I'd certainly not feel you need to go overboard unless you have additional reasons to think that this might be a problem.

Good luck!

Hey Dirk,

No worries - I visited the question first time today and considered it unanswered as the site is perfectly accessible in California. I like to confirm what Search Console says as that is 'straight from the horses mouth'.

Thanks for confirming that the IP redirect has changed, that is interesting. It is impossible for us to know when that happened - I would have expected thing to get indexed quite fast when it changed.

With the extra info I'm happy to mark this as answered, but would be good to hear from the OP.

Best,

-Tom

Hi,

What happens when using HTTP? Are you able to share the .htaccess code?

The same .htaccess setup should work for for both protocols, but with .htaccess the devil can be in the details sometimes. A good tool for testing it is here: https://htaccess.madewithlove.be/

Do other redirects from HTTP to HTTPS work ok? I'm wondering whether your Apache setup perhaps has a different virtual host setup for HTTP and thus a different .htaccess file.

Best,

Tom

Here you go, I managed to dig up informative blog posts for most of the active tools:

Trifecta

http://www.seomoz.org/blog/goodbye-page-strength-hello-trifecta-seomozs-latest-analysis-tool

Competitive Link Finder

http://www.seomoz.org/ugc/competitive-link-finder-provides-qualitative-link-building-ideas

Linkscape

http://www.seomoz.org/blog/linkscape-education-series-learn-the-ins-amp-outs-of-how-linkscape-works

Juicy Link Finder

http://www.seomoz.org/blog/new-premium-services-link-directory-juicy-link-finder-tool-new-pricing

Crawl Test

http://www.seomoz.org/blog/crawl-test-seo-tool

Blogscape

http://www.seomoz.org/blog/announcing-blogscape-and-seomoz-labs

Hi,

I am not sure I follow your concerns around serving an alternative version of the page to search engines - is that concern based on concerns it will be frowned upon or technical concerns?

Using the escaped_fragment methodology would work for your purposes, and would be the best approach. If you have technical concerns around creating the HTML snapshots you could look at a service such as https://prerender.io/ which helps manage this process.

If that doesn't answer your question, please give more information so we can understand more specifically where you concerns are.

Hey,

As Jane mentioned - .htaccess can't change the HTML content of your pages, so you can't replace all the links that would be seen by a user or a browser.

If the links are via a redirection page on your site then you can use .htaccess to redirect those requests elsewhere, so when a user clicks a link it takes them somewhere else instead, but only if those pages are on your site.

Make sense?

Good luck!

-Tom

Hi Jonathon,

Rand mentioned at the amazing Distilled Link Building event last week that this was something that is coming in SEOmoz Pro tools. Hang tight, and I think we'll have it soon.

Hi,

1. I have used CloudFlare for a few sites and never had an issue with this. It is a risk/concern with all shared hosting, but CloudFlare are very proactive about addressing anything impacting their customers, so I would not have a concern on this side of things at all.

2. Again, I wouldn't have concerns here. CloudFlare are very adept at handling large-scale DDOS attacks . Having read some of their post-attack analysis reports, they usually mitigate any impact to customers very quickly. They have loads of customers, and if this sort of thing was an issue I think we'd hear about it fairly often.

3. I can't speak to the % of users that might get falsely identified as a risk and presented a CAPTCHA, but I'd be very surprised if it was as high as 1-2%; I've rarely seen that CAPTCHA screen myself. You should check what CloudFlare have to say on this issue, but I would have no concern here either.

I have never had an issue with CloudFlare impacting SEO performance or impacting the user experience. It has generally performed well for me, but the biggest issue I see with it is people hoping it is a 'cure all' and means they don't need to properly address issues affecting the performance of their site. If your database performance is very poor, meaning dynamic pages take a long time to load, then CloudFlare is not the answer (it may help - but you should address the underlying issue).

I am unsure about the issue with CloudFlare failing when your server is slow - I'd imagine CloudFlare support could help you with this - there may be a configuration option somewhere.

Overall - my suggestion would be that you go for it.

So Google just announced the +1 button, which is there answer to Facebook 'likes' button:

http://searchengineland.com/meet-1-googles-answer-to-the-facebook-like-button-70569

http://techcrunch.com/2011/03/30/google-plus-one/

They should begin showing up now on Google US. If you aren't seeing them, you can turn them on here:

http://www.google.com/experimental/

I want to know? What affect do you predict these are going to have? Is there anything we can do from an SEO point to begin leveraging +1 right from the outset?

seoelevated is correct.

Reference example from Google here: https://support.google.com/webmasters/answer/189077?hl=en