Publishers renew focus on search optimization — and find new tricks

Publishers are putting renewed effort into Google search, and with it, SEO tricks.

Variations on the “What time does the Super Bowl start” trick of answering a question people are searching for might be passé. But other tactics are taking their place. Tactics like  stuffing headlines with keywords and passing off old stories as new may have lost favor with Google. But that leaves publishers to try to figure out what Google wants today and optimize to those preferences. They’re also keen to land the coveted spots in its carousel that sits at the top of Google’s mobile search results, a feature it introduced with Accelerated Mobile Pages.

One popular tactic among publishers is social swaps. It’s widely accepted that Google considers a post to have more authority if other sites link to it. Health and lifestyle publisher Rodale, whose titles include Men’s Health and Runner’s World, has begun putting links in its stories to other like-minded sites as part of a larger SEO push. “If we’re slow in search, we’ll link to a PureWow and they’ll do the same for us,” said Beth Buehler, Rodale COO.

Google has also driven publishers like Rodale to migrate their sites to the https protocol since the search engine said it would prioritize https sites, which are supposed to protect consumers’ privacy. It’s already paid off, according to Buehler: In the January-April period, Rodale’s search traffic increased 32 percent over the year-earlier period. Many publishers also have stripped down their pages to be compliant with Accelerated Mobile Pages, Google’s effort to speed up the mobile web.

“People are still gaming the system,” said Kelly Maloni, head of product at New York magazine.

Behind all this is the reality that it’s getting harder for publishers to get people to come back to their sites. Platforms are less reliable sources of traffic. Facebook and Apple News are encouraging publishers to post their articles so they’re read directly in those closed platforms rather than on the publishers’ sites. Google is displaying more information inside Google itself.

“They’re trying to make their platforms stickier, so there’s less of a reason for people to go to your site,” said Eric Gillin, a digital gm at Condé Nast. “It’s just harder out there.”

Time spent is another area publishers are paying attention to. In the past, New York magazine might have chopped a big article into multiple pieces so it would have more stories to drive traffic to. No more. The current thinking is that Google will reward stories that get more time spent with them. “Now we’re saying, a longer piece can do better,” Maloni said. This is a common tactic in the SEO-driven food category, where it’s taken the form of longer recipe posts, Gillin said. “If before they had 12 recipes, you’ll see them do 25,” he said.

Publishers of news and evergreen content both see big opportunities to gain from search. Google’s algorithm may be as mysterious as ever, but publishers feel like they more control than they do with Facebook because they can see how their strategy is working in real-time.

The Guardian US gets 31 percent of its traffic from search, more than twice the percent it gets from social, and accordingly, it spends more time on search. Its two-person SEO team puts almost everything it publishes through an SEO check (on average 40 stories a day), and gets heavily involved in big or ongoing stories, tweaking, or “rolling,” the headline.

“That can keep us in strong positioning in search, particularly in that organic carousel,” said Ross Maghielse, audience engagement editor at The Guardian US.

For evergreen content, publishers troll for higher search results by removing dates from their urls (or, controversially, on their stories, as if to suggest the content is new). New York magazine created dateless urls in its CMS that it uses for certain articles like its popular annual Best of New York feature, but it does maintain dates on the articles themselves.

Still, if publishers think they have more visibility into what’s working in search, that doesn’t necessarily mean search is easier to game. The publishing landscape isn’t what it used to be when The Huffington Post honed the Super Bowl trick. Other publishers have caught up. And publishers just aren’t chasing scale at all costs as much anymore, so ploys that just get fly-by traffic no longer align with publishers’ business goals.

“The Huffington Post can’t just dominate search the way they used to, which makes it a more competitive landscape,” Maghielse said.

And Google is getting stricter anyway. “They’ve shown they’re not going to put up with the gaming, so there’s no sense in trying to keep up with it,” Buehler said. “So if you’re smart, it’s not a great use of energy to try to game it.”

The post Publishers renew focus on search optimization — and find new tricks appeared first on Digiday.

HTTPS on NYTimes.com

By EITAN KONIGSBURG and VINESSA WAN

We are thrilled to announce that we have begun to enable HTTPS on NYTimes.com, an effort that helps protect the privacy of our readers and ensures the authenticity of our content. This is a significant milestone in the 21-year history of our website, and though it’s taken us some time, we are very excited to share this wit our readers

What’s included?

NYTimes.com consists of millions of pages, so we’ve prioritized HTTPS for areas of our site that receive the most visits. You should already be seeing a padlock next to our URL in your browsers on the following:

What Does This Mean for You?

  • Improved privacy: HTTPS encrypts the data sent between your computer and our servers, making it more difficult for a third party to monitor what you are doing. While HTTPS will not hide the fact that you are visiting NYTimes.com, it will significantly diminish the ability of a third party, such as your internet provider, to see which articles you are reading.
  • Authentic news: Another benefit of HTTPS is that it validates that your computer is communicating with the website you intended to reach, and that any data you receive has not been modified in-transit. When you see the padlock in your address bar, the browser has validated that you are getting authentic NYTimes.com content.
  • Enhanced experience: Some newer web technologies are only made available to HTTPS pages. As we implement HTTPS, we are able to take advantage of these features to make our pages load faster, create innovative interactive projects and provide more personalized content.

HTTPS for the News

The benefits of HTTPS that we wrote about in 2014 remain relevant today. Other media companies have migrated to HTTPS: The Washington Post, Wired, BuzzFeed, The Guardian, and most recently, Quartz. (For more information, the Freedom of the Press Foundation launched a service to track HTTPS implementations on many major media sites.)

It’s been a complex undertaking for us and we’ve discovered a lot in the process. We’ll be sharing a deeper dive into the technical aspects and the challenges we encountered on our journey to HTTPS.

What’s Next?

This is just the beginning, and we intend to bring the rest of our site under the HTTPS umbrella. There is still a significant amount of work remaining, but we are committed to seeing it through. Securing our site is good for our users and the right thing to do. Our core purpose as a company is “to enhance society by creating, collecting and distributing high-quality news and information.” We believe the implementation of HTTPS furthers this purpose.


HTTPS on NYTimes.com was originally published in Times Open on Medium, where people are continuing the conversation by highlighting and responding to this story.

Revised Crossref DOI display guidelines are now active

Crossref DOI Display

We have updated our DOI display guidelines as of March 2017, this month! I described the what and the why in my previous blog post New Crossref DOI display guidelines are on the way and in an email I wrote to all our members in September 2016. I’m pleased to say that the updated Crossref DOI display guidelines are available via this fantastic new website and are now active. Here is the URL of the full set of guidelines in case you want to bookmark it (https://www.crossref.org/display-guidelines/) and a shareable image to spread the word on social media.

This blog is a quick reminder that all Crossref members should now be displaying DOIs in the recommended new format from this month, on any new content you publish online. Please note these guidelines are for Crossref DOIs only, we have nearly 90 million registered but there are others, and not all DOIs are made equal.

The main changes are to display the DOI as a full, linked URL using HTTPS:

https://doi.org/10.xxxx/xxxxx

For background on the HTTPS issue please read Geoffrey Bilder’s blog post, Linking DOIs using HTTPS.

What will happen if you don’t update your Crossref DOI display?

We tell members that they should be working towards making the change even if they can’t do it until later – we recognize that it is not always an easy change to make.

However, if members don’t make the change, nothing immediate will happen (Crossref won’t fine you!) although as more members make the change your display will look odd and out of place compared with other members’ content.

If you have any questions please do not hesitate to contact us.

Crossing the HTTPS Finish Line

Last year, we started transitioning The Atlantic from serving pages over HTTP to using the secure HTTPS protocol. It’s been a gradual process, but today we’re happy to announce that our articles are served 100% over HTTPS.

Traffic to HTTPS pages on TheAtlantic.com

As we wrote in an earlier article, the HTTPS conversion strategy for our stories had several phases:

  1. Enforce HTTPS for newly published articles
  2. Find and update any HTTP embeds in our article archive
  3. Migrate our full archive to being HTTPS only
Redirect the user to the HTTPS version if necessary

We handled the first phase by first adding a bit of code in Ollie, our custom CMS, that both prevented users from adding HTTPS-incompatible HTML into any new articles and then also flagged all of these new articles as being HTTPS only in our database. On the front end, if a user tried to access one of these new articles via HTTP, they would automatically be redirected to the HTTPS version of our website.

Finding and fixing non-HTTPS compatible embeds

We were able to achieve the second phase by scanning our archive for HTTP content embedded in our old articles and updating if possible. This required automatically checking to see if a HTTPS version of the embed existed online and then updating the HTML accordingly.

The final phase, which involved setting the ‘HTTPS only’ flag on all published articles was the simplest technically, however, it actually took the longest to accomplish. This is because one of the biggest obstacles that any site with a sizable back catalog of HTTP content will run into is figuring out how to make the transition to HTTPS without being penalized by Google. Since Google announced in 2014 that they were going to start rewarding sites for using HTTPS, the idea that switching from HTTP to HTTPS could hurt a site’s SEO might seem counterintuitive. However, Google treats transitioning from HTTP to HTTPS similar to changing domain names, and warns that it “can temporarily affect some of your traffic numbers”.

So, while going all in on HTTPS might give us a slight long term boost in our search rankings, we wanted to proceed carefully to avoid the penalties that other media companies have seen. To that end, after enforcing HTTPS for newly published articles, we waited until we had a good sized buffer of new HTTPS content before we began migrating our archive. Next, our analytics team carved our articles up into ten tranches based on search engine referrals, with a few SEO heavy hitters at the top, and the great mass of articles with little search engine traffic at the bottom. Using that data, we could set articles to be HTTPS only tranche by tranche, slowing working our way up the list. By migrating our data in this way, we spaced out any damage done to our search rankings and avoided the negative network effect that might be incurred by redirecting our entire article archive all at once.

Now that we’re delivering all of our articles over HTTPS, we’ll be able to leverage some additional technologies. First, we can use the faster 2.0 version of the HTTP protocol which most browsers only support when coupled with HTTPS encryption. Second, we can work on implementing HTST headers and preloading which will help ensure that browsers never try to access our website using an insecure protocol. Finally, standardizing on HTTPS allows us to use a JavaScript technology known as service workers which enables features like push notifications, improved offline reading, and improved performance.


Crossing the HTTPS Finish Line was originally published in Building The Atlantic on Medium, where people are continuing the conversation by highlighting and responding to this story.

Our Journey to Secure: Transitioning to HTTPS at The Atlantic

The reasons, approach, and next steps

At the beginning of 2016, The Atlantic decided to embrace an industry best practice and transition from HTTP to HTTPS, or “secure.” The decision to devote time and resource to the effort required support and participation across our organization — from our writers who rely on embedding content from a variety of sources, to our advertising operations team that trafficks ad tags, to our developers. And while the decision to move to secure was relatively easy, the process to get there has been a more arduous journey.

What is HTTPS and Why Go Secure?

In 2014, The New York Times called for all sites to transition to HTTPS by the end of 2015. Among the 9 justifications for the move were “Authenticity of News Delivery”, “Privacy” and “Security”.

In a nutshell, HTTPS means that data will be encrypted between our servers and your browser thus reducing opportunities for spying or nefarious interference while you’re reading our site. A user knows a site is secure when they see the “lock” symbol by the URL in a standard browser.

In concept, anything we can do to verify the authenticity and integrity of our site is a no brainer. However, at the end of 2015, Poynter reported that the progress of publishers to embrace HTTPS was slow. Most organizations, including the New York Times, had failed to make the transition.

Our Journey Began

We began our process to transition to HTTPS in April by porting over images and individual elements, so that when it came time for articles to transition to HTTPS, there would be no mixed content on our pages. One of our developers scanned our database to find any of these elements that might break the site post-transition.

Next, we devoted a beta server to testing and addressed third party scripts on the pages, reaching out to third party vendors for HTTPS versions of scripts.

One concern for the transition was that our journalists would inadvertently include insecure images, interactives or other elements in our content management system (CMS). Even though these elements would show up blank in preview, we wanted to ensure errors wouldn’t persist in our backend. To address this, we created a warning that would notify editors on save that their story contained insecure elements.

A Challenge: Insecure Ads

Next, we worked with our ad ops and planning team to change our ad specifications and require HTTPS compatibility from our direct advertisers. We then made a list of our programmatic vendors and began requesting updated tags or code for HTTPS compatibility.

Once we had our tags updated and our QA process in place, we began monitoring the beta site. The most common issue we ran into when testing the secure site were assets that had initially passed QA and later showed up with insecure elements. Often, this was the result of an advertiser changing the creative and inadvertently adding an insecure element, like a tracking tag, after the ad was live.

It was clear that we needed a better monitoring process, and in June we began trials with systems that could do just that. We determined that a key requirement for our new validation software would be to monitor ads on a continuous loop.

Going Live with HTTPS (gradually)

We’ve benefited throughout this process from the learnings of those who’ve gone before us. In particular, these product posts from The Washington Post and Wired were extremely helpful in identifying challenges and pitfalls. Both publishers described gradual transitions to ensure they were safeguarding against search traffic loss and unexpected errors. We knew, we’d want to follow a similar process so we could monitor errors and impact closely.

Once we were comfortable with what we saw in the beta test environment, our first step was to turn off the redirect on visitors that typed in “HTTPS” before “theatlantic.com.” With less than 1% of daily traffic hitting the secure site, we were able to safely monitor for errors. Over a period of 3–4 weeks, we identified one error in a third party script and a handful of third party ad creatives that were not secure.

Next steps

This week, we will be taking a bigger step as we transition our homepage to secure. This will take us from <1% secure to roughly 20% of the traffic being secure. We plan to monitor that change for 1–2 weeks. If all goes well, we’ll move onto making newly published content secure and finally, to redirecting the archive. In total, we are aiming to complete the transition to 100% secure by the end of 2016.

With a little luck, we’ll be ringing in 2017 with a fully secure site. And that’s something to toast to! 🍻

Many thanks to Delaney Chambers for her contributions to this project and this post.


Our Journey to Secure: Transitioning to HTTPS at The Atlantic was originally published in Building The Atlantic on Medium, where people are continuing the conversation by highlighting and responding to this story.

Proudly powered by WordPress | Theme: Baskerville 2 by Anders Noren.

Up ↑