Very hard to prove these things before they're done - good luck with getting buy-in for what you need to do and in undoing the worst of the damage.

Good luck!

You're not the only person reporting odd indexation happenings here on Q&A (see for example this question). And, just like I found for that question, your site appears to have more pages indexed in Bing than in Google - which at least seems to point to us not having missed something obvious like meta noindex or similar.

I did also read Google saying that they had issues with the site: command (link) but I don't think that can have anything to do with your situation as they say they have now fixed that issue, and I couldn't find any other pages on your site even with non-site: searches (i.e. it does genuinely appear as though those pages are missing from the index).

While I am loathe to point just at links these days, I do wonder if in this case it is just a case of needing some more authority for the whole site before it is seen as big enough and important enough to justify more pages in the index.

It sounds as though you should be OK in that case - if they are all site.com/post, then it shouldn't matter how many categories they are in.

In theory you can have Topics and Categories - it all depends on how the site is set up, but I would probably say it's best to focus your efforts on one if I had to guess without knowing the site and all the considerations inside out.

Good luck.

It seems like Google only has a handful of distinct pages indexed at the moment - whereas bing has about 10x as many. So that seems to indicate something wrong specifically for Google.

I'd start by checking your search console - are there any errors? If you use the URL inspection tool and visit the URL in question (studyplaces.com/15-best-minors-for-business-majors/) does it tell you why it has been canonicalised? What happens if you view the page as Google saw it? Is there any chance that you are blocking googlebot / cloaking in any way? Have you had any website outages or downtime?

As others noted, your about page is now missing - did you do that deliberately to see if it resolved this issue?

The answer Google would like you to believe is that it's possible for the word ordering to imply different intents. In reality though, I think it's mainly an artefact of them not fully understanding meaning, or not being able to classify all pages and keywords perfectly.

My colleague Sam Nemzer wrote a post with research on this topic that you might find interesting.

This sounds tricky - it appears to be indexed for me at the moment.

Some things to check:

1. Server monitoring - is the website up and available at all times (including e.g. robots.txt)?
2. Server logs - are you serving any status code other than 200 to googlebot at any point?
3. Search Console - are there any errors recorded, or if you go to the URL inspector during an outage, has it canonicalised the homepage to any other page somehow?
4. I noticed a heavy reliance on JavaScript - and some of the text that appears on the homepage doesn't appear to be returning the homepage on a search for it in quotes (e.g. ["Not just any old snack box, SnackMagic lets everyone customize"] so I'd check for JS rendering issues for googlebot as well

Hope something there helps.

Hi there,

The answer to this depends a little bit on how your CMS / website treats content that appears in multiple categories. The "correct" way of it working is that those pages are still accessible at only one URL (i.e. not at both /category1/slug and /category2/slug ). This is normally achieved either by having a primary category that appears in the URL (and then having that content also appear on the category2 page but not with category2 in the URL) or by having the content available at /slug and appearing on both category1 and category2 pages.

Assuming this is the case, then it's perfectly safe to have content appear in more than one category.

If not, you could investigate whether you can add a rel=canonical link from secondary categories to the primary category. This would be OK but you might want to limit it only to times when content really needs to be in both categories otherwise you may waste crawl budget depending on the scale of your site.

I actually wrote a post about the difference between URL structure and site architecture that you might find useful.

Hi  Jeroen,

Many websites have category or listings pages that contain substantially different lists of links each time Google crawls them. This can be because they are rotating the top listings (like you describe) or simply because the velocity of content creation (and in some cases archiving / removal) is high enough that it appears to change dramatically (think e.g. the reddit "new" page).

As such, I don't think you need to do anything particularly special here - it should "just work" for the page in question - depending on the details, you might want to make sure that there is enough other content on the page that it is substantial enough in its own right.

The other thing I'd consider is whether you want to have more static crawl-paths available to make sure that googlebot always has a way of discovering and crawling all listings - whether you do this via categories, tags, or via some other means.

In addition to the advice and tips you have already received here (in general: be super careful with .htaccess / httpd.conf files, and revert to previous versions if you see unexpected behaviour) one additional tip is to consider turning on logging while you debug the problem.

Note that, in addition to what others have said here, it can often be the case that consolidating two websites in the same industry can result in less traffic than the total the two were receiving previously. This is because it's possible that both were ranking for some of the same queries before the merge, and yet the merge doesn't move the top result up (because the result above is significantly more powerful) and hence the net result for that query is just to remove one result you own from the search result page.

Just a word of caution as you model this impact.

Hi Daniel. Did you get this resolved / did it resolve itself? I'd happily take a look if you'd like if not - just let me know the URL.

You're right that the best plan is likely to look at adding that content onto the mobile versions of the category page (though it's worth rolling out slowly and carefully if you can't split test because we have seen it be good or bad in different circumstances - see this whiteboard Friday for example).

In theory, with mobile-first indexing, Google will be crawling your site with a mobile user agent, and so as long as you are treating googlebot the same as you treat other similar user agents, it should see the page exactly as you do when you visit with a mobile browser (or emulate mobile using chrome for example).

There are various ways to check different parts of this:

1. Check what is actually indexed - by viewing the cached version of the page and / or searching for unique text that only appears on a specific category page "in quotes"
2. Check what google sees using the URL inspection tool in search console and selecting "view crawled page"

Good luck - I hope that helps.

Hi Frankie,

Sorry for the slow reply to this one. I hope it's still relevant to offer some thoughts.

First, at the top level, I would say that the stated reasons don't necessarily mean that you should not have the kinds of pages you describe. My first preference would be to modify the functionality so that the filters you describe users actually using are those sub-category pages. Even if this meant changing URLs (and hence 301 redirecting the pages you currently have), it is possible to have filter / facet pages be indexable and have unique URLs and meta information.

If that's not possible for whatever reason, I would separate my efforts into the micro and the macro:

1. Micro: apply a 80:20 or 90:10 rule to the pages that you are losing - find the small number of most important and highest traffic / conversion pages and find a way to keep versions of those pages (again - even if you have to 301 redirect them, you could create them as static content pages targeting those keywords or something if you had to)
2. Macro: where you simply have no choice but to lose these pages, I think your best bet will be to redirect them to the absolutely best (/ next best!) page on the site for those queries - these might be other (sub-)category pages or they might be individual products or content pages, but at least for the highest traffic end, it'd be worth specific research effort to identify the best redirect targets

One final thought: it's not always the case that the URL has to represent every level in the hierarchy. I don't know your underlying technology, but it might be possible to recreate some of these sub-categories as top-level categories if products are allowed by your CMS to be in more than one category at once. I wrote this article about the difference between URL structures and site architecture that might give more clarity on what I mean here.

Hi Rashmi,

In my experience, the normal extent of a spammy structured markup penalty is the removal of the SERP features that are associated with that markup - and often if you believe the remedy is to remove the offending markup, you don't get the SERP features either so there often isn't that much of a "recovery" that's possible in this kind of situation.

What kind of symptoms are you seeing / how do you know you have an ongoing structured markup penalty?

I don't know of any situations where there are legitimate ongoing penalties even after you have removed all structured markup so I suspect there must be something else going on (either the situation is resolved, but the search console message remains - noting that if you have removed the markup, you've probably lost the rich snippets as well, or the issue that remains is unrelated to structured data).

Can you share more about the symptoms / notices / communications you have had with the Google team? Thanks!

In general, Google cares only about cloaking in the sense of treating their crawler differently to human visitors - it's not a problem to treat them differently to other crawlers.

So: if you are tracking the "2 pages visited" using cookies (which I assume you must be? there is no other reliable way to know the 2nd request is from the same user without cookies?) then you can treat googlebot exactly the same as human users - every request is stateless (without cookies) and so googlebot will be able to crawl. You can then treat non-googlebot scrapers more strictly, and rate limit / throttle / deny them as you wish.

I think that if real human users get at least one "free" visit, then you are probably OK - but you may want to consider not showing the recaptcha to real human users coming from google (but you could find yourself in an arms race with the scrapers pretending to be human visitors from google).

In general, I would expect that if it's a recaptcha ("prove you are human") step rather than a paywall / registration wall, you will likely be OK in the situation where:

1. Googlebot is never shown the recaptcha
2. Other scrapers are aggressively blocked
3. Human visitors get at least one page without a recaptcha wall
4. Human visitors can visit more pages after completing a recaptcha (but without paying / registering)

Hope that all helps. Good luck!

Ugh. Yeah - sorry - no more bright ideas forthcoming from our side. I think you have a clear-eyed view of the risks and difficulties of the different options. Sorry I don't have anything more substantial for you. Good luck!

Firstly - wow - after speaking to a few folks here (at Distilled), we're surprised that you've had such an honest (but useless) answer from the GMB team.

I'm going to continue asking around / seeing if anyone has any genuinely bright or authoritative ideas for you, but on a first pass if I were in your shoes, my first step would be to go back to the people you've already escalated to and continue trying to escalate further / get them to look into it with even more technical people. You can describe what you are continuing to see as you did here, and hopefully it can help them debug. This feels by far the safest option at this stage.

I'll come back to you if anyone comes up with any better ideas though.

What is the business issue this is causing? Are you seeing these 404 / 410 pages appearing in actual searches?

If it's just that they remain technically indexed, I'd be tempted not to be too worried about it - they will drop out eventually.

Unfortunately, most of the ways to get pages (re-)indexed are only appropriate for real pages that you want to have remain in the index (e.g.: include in a new sitemap file and submit that) or are better for individual pages which has the same downside as removing them via search console one by one.

You can remove whole folders at a time via search console, if that would speed things up - if the removed pages are grouped neatly into folders?

Otherwise, I would probably consider prioritising the list (using data about which are getting visits or visibility in search) and removing as many as you can be bothered to work through.

Hope that helps.

Unless I've misunderstood, I'm not sure that aria-hidden is going to be able to deliver what you are looking to do - I don't think you can use it to hide the alt attribute of the image without hiding the image as well.

If you mean adding non-alt-attribute text to the page so that it is visible to sighted users, I would expect that it would make sense to keep that accessible to screen readers as well - it should be useful to all kinds of site visitor, I would have thought.

In general, I would tend to suggest that alt attributes should primarily be used for their intended accessibility purpose, and that this should tend to include more valuable content on the page which the search engines may find useful. I found this guide to be one of the best I have seen on the subject.

As a sidenote, I tend to think alt attributes are over-rated for SEO purposes anyway. In our testing, we have not yet detected a statistically significant uplift from adding alt attributes to images that did not previously have them.

Good luck!

I don't know of an absolute / definitive answer. If it were my site, I think I would be happy to take the chance with Event markup since there is no perfect match, as you say.

Evidence in each direction:

1. Yes - this is OK - Google's schema page talks about "If the event happens across several streets, define the starting location and mention the full details in description.
2. No - this is not OK - the same page says "Don’t promote non-event products or services such as "Trip package: San Diego/LA, 7 nights" as events".

The reason I wouldn't be too concerned about the "no" side is that I think it is reasonable to read that as being about things like flights where the point is getting to the destination rather than things like cruises which are arguably events in their own right.

Good luck!

Some of the best material I have seen on this subject recently is from Kameron Jenkins - for example, check out her SearchLove Boston presentation. She covers a bunch of tools and tips for effective writing. She emphasises the point but from the discussions in the rest of the thread I wanted to emphasise as well, keyword density has never been a ranking factor, and especially these days, the quality of content is paramount. You are likely to choose pages, topics, and themes from your research and with input from search data, but you need to write for your (human!) readers.

Good luck!

I think you know this, but there is no way of guaranteeing getting back to your prior traffic levels in short order (or +25%), nor keeping it steady. Algorithm updates can fundamentally change the winners and losers in a given segment, and there may be no quick win to return to old results as the underlying variables have changed.

Some ideas and thoughts though:

1. I don't know what kind of site you are running, but with ecommerce / lead gen sites, we have sometimes seen that this kind of core update can lead to a traffic drop without a drop in true performance (sales / leads) because the update was actually aligned with user expectations and dropped in areas where you weren't performing anyway (see e.g. slide 116 onwards in my colleague's presentation here). If you happened to find that you were in this situation, you may find that you can make the case to the business that the situation isn't as dire as it seemed at first
2. For practical ideas, I'd advise checking out Marie Hayne's work - see for example her presentation at our recent SearchLove conference in Boston on practical tips for improving EAT (Expertise Authoritativeness Trustworthiness)

Good luck!

Firstly (and I think you understand this, but for the benefit of others who find this page later): any user landing on the actual page will see its full content - robots.txt has no effect on their experience.

What I think you're asking about here is what happens if Google has previously indexed a page properly with crawling it and discovering content and then you block it in robots.txt, what will it look like in the SERPs?

My expectation is that:

1. It will appear in the SERPs as it used to - with meta information / title etc - at least until Google would have recrawled it anyway, and possibly for a bit longer and some failure of Google to recrawl it after the robots.txt is updated
2. Eventually, it will either drop out of the index or it may remain but with the "no information" message that shows up when a page is blocked in robots.txt from the outset yet it is indexed anyway

I think you could legitimately take either approach to be honest. There isn't a perfect solution that avoids all possible problems so I guess it's a combination of picking which risk you are more worried about (pages getting indexed when you don't want them to, or crawl budget -- probably depends on the size of your site) and possibly considering difficulty of implementation etc.

In light of the fact that we heard about noindex,follow becoming equivalent to noindex,nofollow eventually, that does dampen the benefits of that approach, but doesn't entirely negate it.

I'm not totally sold on the phrasing in the yoast article - I wouldn't call it google "ignoring" robots.txt - it just serves a different purpose. Google is respecting the "do not crawl" directive, but that has never guaranteed that they wouldn't index a page if it got external links.

I personally might lean towards the robots.txt solution on larger sites if crawl budget were the primary concern - just because it wouldn't be the end of the world if (some of) these pages got indexed if they had external links. The only reason we were trying to keep them out was for google's benefit, so if they want to index despite the robots block, it wouldn't keep me awake at night.

Whatever route you go down, good luck!

Hmmm. This is tricky. Some ideas - hope something here is helpful:

1. Have you tried "inspect URL" in search console? That has information about canonical selections these days and may be helpful
2. Are the canonical URLs (and no parameter URLs) included in the XML sitemap? Might be worth trying cleaning that up if there is any confusion
3. Cookies could work - but it sounds to me as though that would go against your client preferences as the non-cookie version would have to remove / work without parameters I think - which you indicated they weren't prepared to do
4. Failing all of that, what about picking one category to be the primary category for each product and canonicalising to that (which will have internal links) instead of to the version with no parameters? Could that work? Might nudge towards the canonical being respected

This is a good answer. I'd add two small additional notes:

1. Google is voracious in URL discovery even without any links to a page or any of the other mechanisms described here, we have seen instances of URLs being discovered from other sources (think: chrome usage data, crawling of common path patterns etc)
2. The description at the end of the answer about robots.txt : I wouldn't describe it as Google "ignoring" the no crawl directives - they will still obey that, and won't crawl the page - it's just that they can index pages that they haven't crawled. Note that this is why you shouldn't combine robots.txt block and noindex tags - Google won't be able to crawl to discover the tags and  so may still index the page.

I would have no issue with using rel canonical links in this kind of situation where you cannot control the underlying CMS to the extent that you would need to entirely avoid the duplicate URLs. The only real risk in my opinion is in the canonicalisation not being respected, but if these are essentially exact duplicate pages, I think the risk of that is low (and even if that were the case, the impact would be relatively low too).

Good luck!

I don't have inside information on the official answer, and have not done my own testing, but I would plump for the 410 in this situation. It's the correct answer if you know a page is never going to exist at that URL and it is common enough across the web that I would be confident it would be interpreted correctly.

I hope that helps.

With the caveat that I'm not an expert in the affiliate space, the advice I have typically seen given in these situations is to put all the targets of the links on your site into a folder like /outbound/ and then block that entire folder in robots.txt so that the search engines don't crawl those links / don't see the 301s. I wouldn't have thought that would be sufficient to think that they don't realise that you are running an affiliate model, but there's nothing wrong with that business model per se.

As far as linking out and sending people off to another site a lot, no, that sounds like the right user experience in this situation, and I can't think of any other way of achieving what you are trying to do.

Good luck.

I remember Dana DiTomaso talking about this kind of topic at SearchLove in San Diego. You can see her slides here.

My colleague Tom Capper also talked about local SEO without a physical presence at MozCon in 2018 - slides here.

Hope one of those helps. Good luck!

Hi there. It's a little hard to be certain based on the screenshots you've provided - the best way of verifying this yourself (or for getting me to help) would be to evaluate the actual website from the "outside" - i.e. when not logged into the admin area. I would suggest reviewing what that looks like and ensuring it operates how you expect and want it to. If you would like me to take a look, please share a link and I'll see if I can help some more.

Thanks

Hi there,

As long as the wordpress settings result in serving the new content at the root (www.example.com/ rather than www.example.com/newhomepage) then you will not risk any page authority with this change. The only change that would be visible to google in that situation would be the updated content.

Hope that helps.

Hi Sam. A correctly setup firewall or CDN should not have implications for SEO. If you can share the URL / domain then I can take a look at the specifics, but in principle, you should be fine.

Things to watch out for:

1. Site speed impacts - in theory a CDN should generally be good for site speed, but if you didn't select one primarily for this reason, it's something to check
2. HTTPS - ensure that you keep this consistent through the change
3. Avoid changing URLs in the process (if you have to, make sure you have redirects set up and treat it like a migration with associated risks)

Hi Kathleen,

I would think about this in a few phases (you may not do all of them):

1. "Pure" rebrand - affecting the design of pages on the site, but not which pages exist or their basic HTML structure - this is the safest from an SEO perspective, though you run the risk of damaging conversion rate etc and so it is worth testing as much as you can and rolling out cautiously if it is a large site (see my whiteboard Friday on this for example)
2. Website redesign / rebuild - affecting potentially anything on the site, but staying on the same domain - if as you indicate, you are going to roll the website into the acquirer's site, then I would do my best to avoid this stage - it's the riskiest without significant upside. If you can get away with #1 and #3 then I would do that. If you have to go through this stage, treat it as the serious SEO project that it is
3. Migration into acquirer's site - you described it as "absorb" the client's site - I would expect in most acquisitions that you would end up with some combination of existing pages on the acquirer's site that should be the target of redirects of your client's pages and the need for some new pages (based presumably on existing pages on the client's site). Scoping out this mapping is the most significant part of this step - everything else is a migration project to be handled with the normal care and attention to detail

One thing to mention: we have seen people make assumptions that if you combine websites A and B, that the combined website will have the traffic of A+B. This is rarely the case for reasons of overlap / cannibalisation even if the migration and redirects function perfectly. So you are right to be cautious. The more overlap there is between the acquirer's site and your client's, the lower I would forecast the combined traffic. The more distinct they are (and hence the more your client's site could eventually migrate into a subfolder of the acquirer's site for example) the closer you might get to A+B.

I hope that all helps.

Hi there. What we know for certain is that these kinds of signals show up in manual warnings delivered via Search Console, and are a signal that a human quality reviewer would pay attention to. Everything about exactly what Google is doing algorithmically has some element of guesswork to it, but this is a machine-detectable pattern that I would think would be very likely to be detected automatically and the links discounted.

[Sidenote: it wouldn't be the crawler that did this - it would happen at some stage after that - just a semantic difference, but thought it was worth adding for clarity.]

Ah - I was more focused on the Fiverr side of things and your description of the kinds of links you are seeing come through. I don't have any insight into how the Hoth works or operates, or what tactics they use specifically...

Hi there. Unfortunately, I would err on the side of saying that not only are those links most likely not helping, but there is a significant risk of them **hurting **your performance.

In general, any links that you can just get in this fashion by purchasing them off a public forum with nothing related to any differentiation of your business are very much going to be links that Google is going to want to discount (at the very least - if not penalise).

The mention of "guarantee" in the second paragraph is a warning sign for me too - I'd advise you to dig into the actual tactics and know for sure what is being done in your name and for your website.

Having said all of that, as a general rule of thumb, because of the power-law structure of the web, a few very powerful links can be more effective than many weaker ones.

Hi Jo. So I think that you want everything after code= and before the &.

In the example you pasted, that would be:

4/igAqIfNQFWkpKyK6c0im0Eop9soZiztnftEcorzcr3vOnad6iyhdo3DnDT1-3YFtvoG3BgHko4n1adndpLqjXEE

If that doesn't work (or rather, it doesn't work when you re-run it and use whatever value comes up next time), let us know and I'll pull in someone who has done this themselves (I'm just reading the same instructions!).

Good luck

Unfortunately it's going to be difficult to dig deeper into this without knowing the site - are you able to share the details?

I'm with Martijn that there should be no connection between these features. The only thing I have come up with that could plausibly cause anything like what you are seeing is something related to JavaScript execution (and this would not be a feature working as it's intended to work). We know that there is a delay between initial indexing and JavaScript indexing. It seems plausible to me that if there were a serious enough issue with the JS execution / indexing that either that step failed or that it made the site look spammy enough to get penalised that we could conceivably see the behaviour you describe - where it ranks until Google executes the JS.

I guess my first step to investigating this would be to look at the JS requirements on your site and consider the differences between with and without JS rendering (and if there is any issue with the chrome version that we know executes the JS render at Google's side).

Interested to hear if you discover anything more.

Hi there. Sorry for the slow follow-up on this - there was an issue that meant I didn't get the email alert when it was assigned to me.

There is increasing evidence that culling old / poor performing content from your site can have a positive effect, though I wouldn't be particularly confident that this would transfer across sub-domains to benefit the main site.

In general, I suspect that most effort expended here will be better-placed elsewhere, and so I would angle towards the least effort option.

I think that the "rightest" long-term answer though would be to move the best content to the main domain (with accompanying 301 redirects) and remove the remainder with 410 status codes. This should enable you to focus on the most valuable content and get the most benefit from the stuff that is valuable, while avoiding having to continue expending effort on the stuff that is no longer useful. The harder this is, though, the less I'd be inclined to do it - and would be more likely to consider just deindexing the lowest quality stuff and getting whatever benefit remains from the better content for as long as it is a net positive, with an eye to eventually removing it all.

Hope that helps - I don't think it's a super clear-cut situation unfortunately.

Hi Phil,

Sorry for the slow response to the question - we had a hiccup with the email alerting system and so I wasn't notified as quickly as I should have been.

A couple of resources that might help give you context on the general question about sub-domains vs. sub-folders:

1. Video explainer
2. Overview of URLs generally
3. Recent follow-up showing that moving from sub-domain to sub-folder can result in positive movements

Having said all of that, given that you reference the fact that technical limitations have caused this situation, it's worth noting that creating the content on a separate sub-domain is clearly better than not creating it at all if those are the pragmatic real-world options on the table.

Good luck!

This doesn't ring true to me because:

1. There are all kinds of ways you can find links to your site (referring traffic in GA, link analysis sources like moz's own tools, ahrefs, majestic etc, and tools like Google Alerts)
2. You've already got the link in these cases, so you would have no incentive to "bother" the webmasters
3. In general, my experience has been that most providers want to tell you about as many placements as they can!

Add to this some of the phrasing (e.g. "webmasters we have" -- emphasis mine) suggests that there may be payments taking place or other schemes afoot that place these well outside the Google guidelines.

Per the conversation in the other comments - I would recommend that you get at least a statement of work in place to govern what you are expecting for the money you are paying even if you are not committing to a long-term contract. This could include agreements on any of the above (what information they will provide you with, what you will do with that information etc). At the very least, you should want to understand the techniques in use in order to make your own informed decisions about the risks and rewards.

Hope that helps.

After a bit more digging (and a venture down a character encoding rabbit hole) I haven't come up with any smoking guns (mixed metaphor alert).

I don't suppose there's any chance those pages could have had a noarchive meta tag on them (or nosnippet) at any point in the past is there? It's possible that would remove the link but not remove the cached copy itself.

I'm honestly not sure there is going to be a ton of ROI to going further down the rabbit hole to be honest. I think it's most likely to either remain unsolved or be something you can't do anything about (and we don't even know if it's really causing actual issues).

If you want to continue debugging, I would run through these steps:

1. Take a page like the one you mentioned and duplicate it on a different URL outside of that folder structure and see if that gets a cache link
2. If it does, try 301 redirecting the page without the cache link to the one with the cache link and see if it disappears
3. Try the above but with the redirect the other way around

This will help narrow down what's going on - but doesn't guarantee that it'll be fixable, nor that there is actually any value to getting the cache link back.

If you have any more evidence on the other issues you referred to (featured snippets etc) let me know and I can look at that separately.

Let me know if you dig anything out. Good luck.

Hi Fred. Just having a dig into this. A couple of things I have noticed so far that won't be causing this issue but that you might want to know about:

1. The page you mentioned is in the cache - you can see the cached version by going to cache:https://www.jet2holidays.com/destinations/balearics/majorca -- the cached html appears to match the live html so there doesn't seem to be a crawling or indexing problem
2. Your sitemap.xml link in your robots.txt goes to the http version which 301 redirects to https
3. There are warnings firing in the console in Chrome about distrusting your SSL certificate provider in an upcoming release: https://security.googleblog.com/2017/09/chromes-plan-to-distrust-symantec.html

Hi there. There are a number of ways in which this is a bad idea - as others have pointed out. But in particular:

1. What you are doing may manipulate the "bounce rate" you see in analytics, but won't affect the % of users who return immediately to the search results after landing on your page - which we know is one of the ways Google evaluates the quality of their own search results
2. Going via an interstitial page is on its own not great UX, but having a delay on that page just makes it more likely that a user will give up and leave immediately - and also have a greater chance of remembering your site as being a poor UX and be less likely to return

At an overarching level, there's nothing wrong with having external links off a page. This is normal and expected on any site.

I would say you should put all your efforts that are currently going into manipulating this behaviour and these metrics into improving the user experience of your site to make it better for the people who do find it.

I hope that helps.

Yes - of course. Happy to take a look.

Hi Lori,

On closer inspection, I think that only the rewriterule should have the [L] flag and that placing the specific Redirect at the top of the file should work fine without chained redirects as the other commenters suggested. I tested that here: http://htaccess.mwl.be/ and it appears to work fine using the following .htaccess - can you confirm with your developer that this is what they were trying?:

Redirect 301 /old.php https://www.clientdomain.com/new.php

RewriteEngine on

if non-SSL and one of these, redirect to SSL

RewriteCond %{HTTPS} !on
RewriteRule ^(.*)$ https://www.clientdomain.com/$1 [R=301,L]

Hi Lori. The solution the other commenters have suggested is definitely the way to do this - so it sounds like it needs more debugging. I suspect it's to do with the [L] option being needed on the specific redirect once it's moved above the general http-->https redirect. This stops other redirects below it firing, if I remember correctly.

If that doesn't work, do you want to share back here the specific different htaccess files the developer has tried?

Yeah - there is various speculation about how signals or authority traverse folder structures (see for example this whiteboard Friday ) but I haven't seen anything suggesting it's permanent - all of this may be an argument for adding /famous-dogs/ at some point, but I wouldn't personally stress about it not being there at launch.