Welcome to the Q&A Forum

Hi Chad,

First off, you're right to be thinking about adding product attributes for the size, colour, etc. You should definitely do this.

I wouldn't recommend tags unless there's a strong reason to use them. Tags can be of genuine use on a blog, by providing users a way to navigate a group of related posts, without the blog author having to devote a whole category to it. But eCommerce sites, depending on their size, can already have a pretty difficult time with duplicate content, and it's hard to see how tags would improve the user experience more than tightly-focused subcategories.

If you have a category called "beds", for example, it makes more sense for "double beds" to be a subcategory within that, than to be its own tag. WooCommerce does support nested subcategories, which should allow you to get pretty granular if needs be. You can make use of breadcrumb navigation this way as well.

Finally, on the subject of product attributes again, note that WooCommerce adds attribute filters to the URL as a parameter. So if searched for double beds on your site, the URL would resemble the following:

yoursite.com/beds/double-beds/?min_price=250&max_price=600

You should make sure you've got rel=canonical in place. Also, given that your client is a search engine, I imagine they'll have quite a lot of product pages. To help Google use their crawl budget efficiently, you might add some lines like the following to the robots.txt file, so Googlebot doesn't try to crawl any commonly-used parameters:

Disallow: ?min_price=

Disallow: ?max_price=

If you want to prevent member-only pages from showing up in Google's index (and I assume that is what you're after), then what you want is "noindex", or ideally just to block the pages in robots.txt. A quick look at your site indicates that there's members-only content in the 'resources' and 'presentations' folders (though of course there may be others you also want to hide). Then, in your robots.txt file, you'd put these lines:

User-agent: *

Disallow: /resources/

Disallow: /presentations/

Now even if Googlebot discovers these pages somehow, it won't crawl or index them, and you won't see these pages showing up in a Google search.

There's a good, detailed article on this very issue from PMG. Does this answer your question? If you don't think it does, can you provide more detail about your app, as this will help you get better answers.

When was your app last updated?

Are you referring to having 4 stars overall (i.e. over all versions of your app)? Or is that the star rating for the most recent version?

How many reviews does your app have, for the latest version and over all versions?

Unfortunately, there is no precise answer. The time taken will depend on how regularly Googlebot crawls your site, and how quickly it re-arranges the rankings for your site and in your industry. The short answer is: think weeks rather than days.

For example, if your domain is a powerful one, is frequently crawled, and has pages which rank well -- making this page something of an exception -- you could be expected to recover quite quickly. Perhaps even within a week or two. But the less these factors apply to you, the slower you can expect this process to take. Recovery will also depend on what else is happening at that time -- what are your competitors doing, how is the SERP changing, etc.

I'm sorry not to be able to give you a more precise answer. You shouldn't worry too much that three days have passed without much change. I wouldn't usually expect a full recovery within that time.

If you've done all you can with this page, raise that point with your boss if you have one. Show him/her Google's official guidance -- look right at the bottom of that page for their warning that the process takes weeks -- and move your workload towards other tasks if you can.

Hi Ken,

It depends a little on how the complaints are organised within the site structure, what links they have, and what traffic these pages bring in. Unless you think domain authority is a particularly big factor in the competitive space the site operates in, I wouldn't fixate on DA. Questions you do want to answer:

• Crawl the whole site, preferably using the Google Search Console and/or Google Analytics API with Screaming Frog. Do these complaints bring in (useful) traffic? Surely part of what makes the 311 service useful for community managers is that people in their community can easily comment and see the comments of others? Thinking further down the line, if the site is difficult for people in the community to find, will they use it less, and thus will community managers see less value in the service over time? Indirectly, people leaving complaints is probably a good thing for the service; do they usually do this after searching for "potholes on main street"? This is all guesswork on my part, as I haven't seen the site.
• If you do have a lot of traffic to the complaint pages, is it useful traffic? Could you afford to lose it (because that may happen if you noindex)? Remember to bear in mind the second-order effects: if nobody complains any more, the manager doesn't need a 311 service!
• Do you actually have valuable (external) links to the complaints? We can't guess at that—the only solution is to use Open Site Explorer, ahrefs, Majestic, etc...

Without knowing more, I'll just say: there probably isn't value in having an indexed page for each complaint, but there might be value in having indexed collections of complaints, optimised for neighbourhood or street. So if there are 6 complaints about potholes on main street, a first step might be for each individual complaint-page to canonical back to the page detailing all complaints about main street. And if complaints are really that brief (1 or 2 sentences), eventually I'd prefer to change the site structure altogether, so that each complaint didn't get its own page at all, but that I had one page for each neighbourhood/street/etc, with the complaints listed there and preferably summarised in some way (i.e. "8 pothole complaints", "9 traffic light complaints, etc.) That kind of view might be useful if I was a resident of the place. You would still have to deal with pagination, especially if the number of complaints is large, but that's still going to be far fewer pages than if you have one for every complaint individually.

So it sounds as though you have:

1. A ".in" site for users in India, and
2. A ".com" site for users outside of India.

And that almost all of their content is the same. For this, you need to implement hreflang tags. You can read the Moz guide on hreflang tags here. For each on the ".in" site, find the similar page on the ".com" site, and then add hreflang tags to both. As an example, if I had the following two pages:

1. www.mysite.in/example.html
2. www.mysite.com/example.html

These two pages have the same content and are both in English. I would add the following hreflang tags to both of them:

Notice that the second link there has only a language code - not a country code. The ".com" domain is targeted at users speaking English, whereas the ".in" domain targets English-speakers in India. If you need to add more languages, you should try generating some hreflang tags with Aleyda Solis's hreflang tag generator tool.

Finally,  if you want to check that you have implemented hreflang correctly, Distilled has released a tool at hreflang.ninja.

If you implement hreflang correctly, Google search results in India will begin to show the ".in" domain. You can then remove the 302 redirect.

Hi Maurice,

Sorry for the delay in getting back to you. To address points 2 and 3 that you've raised there:

2. I'm still seeing this behaviour on the site, and it persists across different browsers. I've attached some images to show what I'm seeing. However, if I then click on the English flag (to visit /en/), and then click the Netherlands flag, a cookie is set: jfcookie[lang]="nl". After this cookie is set, the homepage appears in Dutch for me. So it seems as though visitors to the homepage of your website are served English-language content based on the absense of a jfcookie[lang] cookie, or based on their IP address -- you would have to check with your developers which is the case -- and it's only after visiting one of the other languages and then switching back to Dutch that the homepage will appear in Dutch.

3. I don't believe you would see a rankings boost from doing this. I think that, provided x-default is correctly set (to English, in your case), and this issue with the language cookies/IP address is corrected, you can expect Google to figure out the correct page to show in the results for each country/language combination. I do hear what you're saying about most of your customers speaking English, but I also think that, given you use a ccTLD, it could create a strange user experience to have English content on the homepage and Dutch in a subfolder. And x-default largely solves the problem of most of your users speaking English. I don't think there's enough upside to justify the effort.

NgA7duW oG21GhC yV7Qtre 8flDbPz

There are a few issues with the DNS that I can see. First off, the email address in the SOA record is wrongly formatted, so won't receive mail. While that isn't the source of your issue, your IT people should change it so that they can receive messages about the DNS. Change this:

jliodns.admins@ril.com.

to this:

jliodns\admins.ril.com.

(Copy all of that exactly, including the dot at the end of the line.)

Secondly, there are different SOA serial numbers available. There are four nameservers for ajio.com, and they are ns1.ajio.com, ns2.ajio.com, ns3.ajio.com, and ns4.ajio.com. When I query ns1, ns2, or ns4, I get back a line like this:

ajio.com. 3600 IN SOA ns1.ajio.com. jiodns.admins@ril.com. 2016052708 10800 900 1209600 86400

But from ns3 I get this line:

ajio.com. 3600 IN SOA ns1.ajio.com. jiodns.admins@ril.com. 2016041301 10800 900 1209600 86400

The difference is the serial number (the bit after ril.com.): it's 2016052708 in the first case, and 2016041301 in the second. These numbers should always be the same. It looks from this line as though the ns3 nameserver should be fetching the newer serial number every 10800 seconds, yet it clearly isn't because it has a serial number from April 2016, while the other three nameservers have a serial number from May 2016. That's still not enough to explain your issue, but basically, your IT team need to investigate the performance of their nameservers, because this may be the symptom of a wider issue.

Good places for them to start are here and here. The first of those two links is the Pingdom test that Nicolas linked to, but with the important difference that it's checking ajio.com, rather than www.ajio.com.

I'm afraid we'd need a little more information to give a good answer. What is the problem exactly; what do you mean by "being flagged as 98% similar in the code"? The HTML source of the two pages is likely to be very similar, but this is to be expected. The only thing "triggering" the duplicate content is the fact that neither page has much in the way of unique text. I don't recommend stuffing lots of text in there, though, if it isn't going to be useful to the user.

I think the more important point here, though, is to focus on the real world impact, and not on a score given by some page-similarity-scoring tool. What is the real-world impact? If you're worried just about the score given by a tool then don't be; there will be better places to focus your attention.

Hi Maurice,

Yes, that's right: the Hotel Nicolaas site is behaving correctly. When I visit the homepage there, everything is consistent and in English, and the language cookie is set to en-GB. Even when I manually change that cookie value to nl-NL, the content is still in English, because I'm on an English-language URL. To get Dutch content I have to visit the /nl/ directory. That's a much better setup, because there's no way to end up with duplicate English-language content: the URLs are consistent.

Best Regards,

Stephan

It's an interesting question. I'll extend your example slightly, so that we have:

• Page A, with a canonical pointing to Page B
• Page A also has a regular link to Page C
• Page B does not link to Page C at all

At the crawling stage, Googlebot will parse all of the links on Page A. So in this case it discovers both B and C (if it doesn't know of their existence already). This is uncontroversial stuff—the use of the canonical tag doesn't affect crawling/discovery.

You might then assume that Google—if it decides to obey the canonical instruction, which of course it doesn't always do—will pass all of Page A's link equity to Page B (minus the small fraction), and then no longer count that link from A to C in the link graph. Almost like a redirect, but for bots only.

However, that doesn't seem to happen. The link from A to C is still included in the link graph. PageRank (or whatever's replaced it) may still flow through that link, even though Page A is not to be indexed.

So to answer your original question, the content of Page A will not be ignored, and neither will its links. The unclear bit is how much Google will value that link from A to C.

Hi Mike,

I wouldn't worry about it—it won't have a major impact. Google will see all those H1 tags, but unless they get the sense, from the rest of your content, that you're relentlessly stuffing the keyword into the article text (and it doesn't sound like you are), it'll be fine.

What I would want to make sure of, though, is that Googlebot is definitely rendering the page in the way you expect. Sounds as if, rendered properly, only one H1 and header image should be visible on each device type? You should take a look at the page using the Fetch and Render tool in Google Search Console to make sure that, whether as desktop or smartphone, everything looks as it should. If you're carrying out this exercise across many pages on your site, you will find it faster to use Screaming Frog's "render screenshot" option.

Hi Maurice,

Both of these pages are on the same root domain, because you've (sensibly) used subfolders for languages, instead of subdomains. The arrangement you're thinking of switching to does sound as though it better describes target market: it'd be nice to see x-default set to english, if that's the language spoken by the majority of your visitors/target market.

When I visit the homepage as Googlebot, the hreflang is "nl", but the html lang is "en". Also, the page content appears to be in English. When I then navigate to hotelcitadel.nl/en, I get exactly the same English-language content, with html lang equal to "en" again, and hreflang "en".

The other languages work OK, and are crawlable, but you should correct the duplicate content issue between the homepage and the /en/ subfolder, and also the discrepancy between "html lang" and "hreflang" on the homepage. It should either be definitively in English, for all users, or definitively in Dutch. Perhaps you're using an IP redirect to determine language on the homepage? If so, I'd suggest not doing that. Your other languages seem to be set up OK.

Did the "pending" message go away in the end? Unfortunately you're fairly limited in what you can do with this. The message likely indicates/indicated that one of the following was true:

1. Google had difficulty accessing the sitemap (though you did say no errors)
2. It was taking a long time to do it because of the large number of links

You could try splitting your sitemap up into several smaller ones, and using a sitemap index. Or have you done this already? By splitting it into several sitemaps, you can at least see whether some index and some don't, whether there do turn out to be issues with some of the URLs listed there, etc.

You can also prioritise the most important pages by putting them into their own sitemap (linked to from the sitemap index, of course), and submitting that one first. So at least if everything else takes longer you'll get your most important landing pages indexed.

What exactly are you planning to render server-side? In principle, you shouldn't have anything to worry about if you render everything server-side, provided the rendering isn't so slow that it affects Google's measures of page speed.

What do you see when you use the 'Fetch and Render' feature in Search Console at present?

Hi Brandon,

It isn't possible to target YouTube channels by location, so I wouldn't recommend creating and maintaining several different channels.

Given that you seem to be talking about videos which are designed to convert (or are viewed close to the point when a customer does convert), I'd actually suggest that YouTube is not the right platform for you. The videos that you're putting all this effort into are going to cause youtube.com to rank—not your website. And the click-through rates from YouTube to your site will be poor.

To really get the most from this kind of video, use a service like Wistia, because it'll allow you to host the videos on your own site, and get credit for that in search results. Phil Nottingham gave another answer on this forum which explains this really well. In a nutshell, YouTube is good at mass reach, spreading a message, raising your profile—think "Dollar Shave Club"—but performs poorly for video content that's designed to convert. Very few people will click through from product description videos on YouTube, so you'll leak traffic unnecessarily. For product descriptions, demos, etc, you're better hosting it on Wistia and embedding on your site.

This will also allow you to fully control geo-targeting, because you can use hreflang on your product pages. Let's say that I have a UK shop in the /en-GB/ folder, and a French shop in /fr-FR/. I can now have the same product listed in each, using the appropriate video and translated description, and use hreflang to tell Google that these pages serve an equivalent function for users in those different locations.

Stephan

Hi Neil,

Don't host the video in two separate locations. You don't want to publish it to Youtube and also store it on your own server, for example. In light of your latest comment, I'd suggest you publish the videos to Youtube, embed those videos on your site, and encourage the hotels to do the same. You should associate the Youtube channel with your own site, and provide links back to your site from the videos (as Andy suggested). Follow the steps outlined in Youtube's guide.

In an ideal world -- a world where all 90 hotels were happy to link to your website -- this advice might be different. Ideally, you'd have links to your site. But if you self-host, it seems likely that you'll have hardly any views: your hotel partners won't link to the videos, and the videos won't be easily discoverable. By hosting on Youtube and encouraging video embeds among your hotel partners, you can at least, as you said, generate a lot of interest around the content. Google does favour Youtube videos in SERPs, so this strategy should help your Youtube channel perform well for queries related to your partner hotels. You can use cards or annotations in the Youtube videos to direct visitors to your site, as well as providing a link in the description.

Having read through your conversation with Ruth, it looks like there aren't many options open to you.

Your client might be able to use a reverse proxy. I'll walk you through a very simple example with Apache, but the same principles hold for other web servers. I should warn you too that proxies can be fickle, and it may be difficult to persuade the developers to put in the work!

Let's say we host the existing website at example.com, and the new site – or what exists of it so far – at staging.example.com. So there are a couple of different DNS records, with the root domain pointing to the IP address of the old server, and the staging subdomain pointing to the IP address of the new server.

Let's also assume that we're migrating a directory called "/foo" for now. We now want those URLs, and only those URLs, to be served from the new server.

We would then use ProxyPass and ProxyPassReverse directives on example.com, to route those requests to the new server:

ProxyPass /foo http://staging.example.com

ProxyPassReverse /foo http://staging.example.com

The first line says "proxy requests to example.com/foo to staging.example.com/foo instead".

The second line is essential because let's say that one of the URLs in /foo is a redirect. Specifically, let's imagine that staging.example.com/foo/1 is a 301 redirect to staging.example.com/foo/2. Now when the user visits example.com/foo/1, their request is proxied to staging.example.com/foo/1, which is in turn 301-redirected to staging.example.com/foo/2, and this is what will show in the address bar (and to Googlebot). That's what you don't want because then the subdomain is visible to Google. So the point of the second line is to say that when the redirect takes place, it should be adjusted back to the form of the original request before being returned to the client. So now, with that second line in place, the request chain looks like this:

Client requests example.com/foo/1

That's proxied to staging.example.com/foo/1

That's a 301-redirect to staging.example.com/foo/2

And that URL is then adjusted back to example.com/foo/2 before the user sees it!

As you migrate sections of the site, you would add new ProxyPass directives to proxy those directories. Then, when you've migrated the whole site, you change the DNS so that the root A record now points to the IP address of the new server, remove the DNS record for staging.example.com, and ditch the old server.

You'll need to ensure that the developers controlling the old site implement the proxies correctly and that there's a sensible mapping of old directory structures to new ones. Your life will be a lot easier if you can minimise the number of redirects taking place on the new server. Good luck!

Hi Fredrik,

How did you set up the goal? Did you use any regular expressions? Please attach a screenshot of the goal configuration. I've attached a screenshot example here.

Thanks,

Stephan

K2eOW9H

It would be useful to see an example of what you mean, but the answer is probably not. What to do first is:

1. Ensure you set up hreflang correctly, so that Google understands your Chinese-language page on New York and your English-language page on New York are functionally equivalent.
2. Use a good rank tracker, and configure it to check your keywords on each of the country-level Google sites you're interested in (Google.co.kr for Korea, and so on). See whether the correct page is showing up when you track ranks for the foreign-language name, and for the phonetically-translated name.
3. Check Search Console for the appropriate pages, using the country filter to look only at the kinds of queries and clicks you're getting from each of the countries you're interested in. See whether people are actually searching with the Asian-language name for the city, or with a phonetic translation. See whether people are searching for the English name (they might be).
4. If, after looking at your rank tracking and search console results, you think there are many people in Asia putting English-language city names into their queries, at that point you could consider going ahead with this idea. Even then, try it on just a few of your city pages at first—not all of them—and continue to refer back to your rank tracker. What you don't want to see is any direct competition between different language versions of the same page, in the same SERP.

Hi Jamie,

For the reverse proxy method, the search engine will perceive that the blog is on the main domain (domain y). As far as any user or Googlebot is concerned, the blog is on domain y in a subfolder – they never see domain x. If you do this, your main challenges will be:

• Making sure that domain x can't be accessed directly (otherwise, your entire blog will exist in two places). They should only be able to access the blog by visiting the correct subfolder on domain y. Domain x can be configured to only accept connections directly from domain y.
• Making sure to configure the proxy correctly. They can be tricky, and may take up some of your team's time.
• Making sure everything remains fast. Although Googlebot has nothing against proxies, if the inclusion of the proxy introduces a big delay to the page load time, that's going to have a negative impact.

Hi again Fredrik,

Sorry that it's taken such a long time to get back to you. This is an unusual problem, though!

As you haven't used regex, the top candidates would have to be:

1. Some historical change in the goal criteria, or
2. You have another event somewhere with the same category

Have you verified that neither of these is the case?

Hi Mike,

Ideally, yes, you'd just have the one URL. If you were setting up a site from scratch, I would tell you to avoid having the same content on those two different pages, because we don't want to create any duplication where it isn't strictly necessary. An example of when it is strictly necessary would be something like a ?sort_products parameter which changes the order products are displayed on a page. There's no way to do that without some duplication, so the canonical tag is useful. It's good practice to avoid having more versions of the page than you need because it reduces the number of ways things can go wrong.

But as this structure is already in place and seems to be working OK -- only one version of the page is indexed -- I would leave it as it is. Messing around with the canonical now will likely do more harm than good. There aren't any definite negative effects for your SEO by leaving things as they are.

As for your question about aggregation, I assume you mean in Google Analytics? No metrics will be aggregated there -- the two pages will appear as separate URLs in your reports. The aggregation that matters for indexation is link equity. When you get links to example.com/page, it will help the rankings of the example.com/category/page URL because that's the canonical version.