Welcome to the Q&A Forum

OK, now that I understand the reasoning...

I believe there's a better, less-risky approach. What I would do is write a completely new post based on information from the old post. At the same time you publish the new post, go back to the old version and add these two things: a canonical tag pointing to the new version, and a bit of _very readable _text at the top linking to the new post. Something like "Hey, thanks for your interest in our content. Feel free to read on, but we thought you should know we've updated this post which can be found here: link"

This accomplishes a few important things. It eliminates the need for a risky project that could affect your entire site just for the ability to update posts (which I'm guessing doesn't happen too often, what percent of posts get updated?). The canonical tag removes the dupe content risk so you're not cannibalizing your own content. And leaving the old post there gives people the opportunity to discover old content that, while possibly not relevant anymore, still demonstrates you've been a trustworthy source of information for a long time.

Jeff,

Based on the traffic you say this blog gets, I'm assuming its rather large and has hundreds, if not thousands of posts. Which leads me to one simple question:

Why? This seems like a HUGE amount of risk and a pretty decent amount of work to go into something that's really not going to provide any benefit.

*edit: It should also be noted that just because Google has recently stated that redirects now pass all link juice doesn't mean you should go needlessly add a massive amount of redirects. There are other implications that redirects have, like load time for example. If you have 1,000 redirects, every single one of those is going to be checked before any page on your site loads, which takes a lot of time.

Looks like there all there, check this query. Am I missing something?

Hey Martin,

That's a great follow-up question. In my experience, the only time 301 redirects significantly impact page speed is when you have entirely too many or when you have a bunch of redirect chains (redirects that point to other redirects URLs). Think of an HTTP > HTTPS more like a URL re-write, where every URL requested from the server gets re-written to HTTPS. It's a much quicker redirect than a standard /old-page.html > /new-page.html. Additionally, Google isn't going to start dinging sites for minuscule load time lags from a secure redirect since they're recommending site owners make the switch.

Hope that helps answer your question.

Hi,

Google used to weigh 'Read More', Tabbed, and accordioned content slightly less than immediately visible content. However, with the recently increased emphasis on user experience and their mobile-first mindset, they've since changed their stance on this type of content. More details including statements from Googlers can be found here: https://www.seroundtable.com/google-content-tabs-hidden-change-22950.html

Hi,

The value of an inbound link is not discounted if it points to http and you redirect it to the secure version of that URL. John Mueller of Google stated this earlier last year in response to a lot of people asking the same question. No need to reach out to site owners for updates.

Hi,

Don't let someone else benefit from content you worked hard to create. If they want to reference it, they can link to that particular piece of content within their own content. So option number one is the best of the 3 you've laid out, I'd be picky about how much of a teaser you allow them to copy though. Give them enough to want to click the link to your site, but not so much that they don't need to click that link.

Hi,

I'd definitely recommend using absolute URLs for canonical tags. Part of their benefit is preventing duplication due to www vs. non-www and https/http issues. If you're using relative, you don't get to specify protocol or www preference.

Additionally, you don't want to only solve for Google. They've obviously got the largest share or organic search, but that other search engines should still index/crawl content accordingly.

The line between SEO and PO is thinning every day as Google puts more and more emphasis on the searcher's journey through the entire inquiry>engagement>action process.

HA! I was totally joking, but it's hilarious that you did this AND that the results came out in favor of the world's most hated font.

Only if it's comic sans.

Ok, gotcha. Add the following directives:

Disallow: /shirts/?

This prevents crawling of the following:

• /shirts**/golden/**?minprice=10&maxprice=20
• /shirts/?minprice=10&maxprice=20

Allow: /*?resultspage=

Allows crawling of the following:

• /shirts/navy/?resultspage=02
• /shirts/?resultspage=01

Disallow: /shirts/?* will only block URLs that end with /shirts/ before beginning a parameter string. If you want to block /shirts**/golden/**?minprice=10&maxprice=20 you'll have to add the asterisk before and after the ?

What the end goal here? Preventing bots from crawling any parameter'd URL?

Hi Luke,

The second developer is correct....well, more correct than the first. Your example of /shirts?minprice=10&maxprice=20 would not be blocked by this direction, since there's no slack after shirts.

For future reference, you can test how directives function in Google Search Console. Under the 'Crawl' menu, there's a robots.txt tester in which you can manually edit the robots.txt directives (they don't apply to the live file) and enter test URLs to see which directive, if any, would prevent crawling.

You are correct in your assumption that a * on either side of the ? would prevent crawling of both /shirts/blue?mprice=100&maxp=20 and /shirts/?minprice=10&maxprice=20

Unfortunately, I don't think there's any easy/fast way to do this. I just ran a test to see how long it take Google to actually obey a noindex tag, and it's taken a little over 2 months for them all to be removed. I had 2 WP blogs that I added the noindex tag to all category, tag, and author pages and monitored the index count 4 or 5 times per week by running site:example.com inurl:/category/ queries. There was a lot of fluctuation at the beginnning, but eventually took hold after about 2 months. On one of the sites, I did add an XML sitemap with only the noindexed URLs on it, submitted it via Search Console, but that didn't seem to have an impact on how quickly they were dropped out.

See the screenshot below of my plotting of indexed pages per subfolder:

jHm7CkD

Hi,

I wouldn't measure your copywriter based on WPM, I'd focus instead on the quality of the writing. I recommend measuring based on the performance of the content. Is it helping improve rankings? Driving traffic? Nurturing leads? Increasing sales? I don't know what your line of business is, but I would choose some KPIs by which you measure the effectiveness of the content being produced. It doesn't matter if it's 1 WPM if that creates 3x as much revenue as content that was written at 100 WPM.

HI,

For your homepage, you're probably pretty safe to proceed with updating. In most cases, the vast majority of organic traffic coming to the homepage is branded, meaning they searched for your company's name or some close variation. As long as all of the key elements retain your brand (title tag, h1 tag, meta description, copy, footer with name/address/phone) stay intact, you shouldn't see a decline in organic traffic. BUT, to be safe, I recommend checking Google Analytics to see what percent of your organic traffic enters through the homepage. If it's the lion's share of your organic traffic, you might want to rethink this plan.

You can find more details about how a reverse proxy works here. Regarding the setup, unfortunately that's outside of my wheelhouse - we had to rely on the tech support team to help out with that.

Hey there,

Sounds like you need a reverse proxy. I recently had a client that was going to migrate small portions of their site over a few months, and this is what we ended up recommending. The situation was this (sounds similar to yours): The client was moving a site with about 1,800 pages from one development firm to another, each with their own proprietary CMS and hosting services. The reverse proxy was essentially a connection between the 2 servers. A URL was requested on server 1, the original developer, the reverse proxy mapped that URL to content on server 2, the new developer. The result was the URLs from server 1 stayed the same, but the content came from server 2 for any URL that had been mapped in the reverse proxy.

NOW FOR A WORD OF CAUTION: This reverse proxy worked great, until security settings on one of the servers prevented requests from coming through, which resulted in dead URLs. So if you're going to move forward with this, be sure that your servers will play nice with each other and not block requests from the other.

You don't necessarily need to change domains to ccTLDs. There are a number of ways to help Google differentiate the location targets of 2 different sites. 2 of the simplest ways to do this are by specifying a country in Google Search Console and using hreflang tags. You will likely run into some issues by having a single domain targeting "all other countries".

If you haven't already, I highly recommend checking out Moz's guide to international SEO. This should provide you with all the methods for country targeting and from there you can determine what would work best for your situation.