Friday, 23 June 2017

How content drives revenue (and how to prove it)

In business, revenue is often the bottom line. Let’s face it, as marketers, if we’re not driving new customers and business isn’t growing, we’re not really doing our job. It’s up to us to drive business along with the sales team.

Something that intrigues me is how few people seem to understand that you can and do drive revenue with the content you create. I’ve had clients ask how you measure the success of a content marketing program, and it’s not a secret that we should keep guarded. We should be showing our clients exactly what we’re doing to drive revenue for them. By showing what we’re doing, we’re showing our worth and helping them understand what content is doing for their bottom line.

Whether you work for an agency and help clients or are in-house, you have someone you report to — be it a client, boss or board. And while within the industry, we feel that content is second nature, the reality is, it’s not in the broad picture. Many people outside of our niche industries don’t fully understand content marketing. Does your mom, dad, best friend or spouse really understand what you do for a living? Most don’t.

Driving revenue with content marketing

So how do you drive revenue with content marketing?

The most straightforward answer is found simply by looking inside your analytics account and finding out how much revenue each page or post has generated for your website. You can easily find out what your best-performing pages or posts are.

With some of my clients, we’ve found that inspirational content drove lots of revenue. For example, a major home goods retailer found great success with their blog posts that focused on design inspiration.

If we wrote a post that showed customers how to create a current season trend at home for less, we saw a big return. Customers liked being able to shop the blog post. We’d link the product URLs right in the blog post, and that allowed the customer to easily find the items. But it also allowed us to track the referring traffic to those URLs and see how much came from the blog post itself.

Behind-the-scenes or preview posts

Another great revenue-generating piece of content is often the behind-the-scenes or preview posts for a brand. We often find that the loyal customer base (i.e., the blog reader) wants to know what’s going on before the public. If we create a blog post that highlights a new product line and share a few sneak-peek images, we can start to create a bit of excitement over the launch.

If we want to track revenue on that post, we can go several routes — one would be to follow the referral traffic from the post URLs once the products are available. This route is a little challenging if the product is not available online yet.

Another option is to offer a coupon that’s available only from that blog post. If you’re looking to drive to retail, that coupon could be good in-store only. If you use a unique coupon code on it, you have an easy way to track the revenue from the blog post for the preview.

If you’re concerned about people other than the post readers finding the coupon, you can always exclude the post from your XML sitemap and hope that Google doesn’t index it. It’s not 100 percent guaranteed that Google won’t index it, but in most cases, it works.

Content additions/changes can lead to revenue

If you have an e-commerce site, look at your product page. How well-optimized is it?

I don’t mean does it have a Title Tag, Meta Description and H1 tag? Do you have schema markup? Are you using a review system for ratings and reviews? Do your reviews, ratings, price and in-stock status show in the SERP? Is there a size guide available? Do you have a product video if it would make sense? Are there comparison guides or charts if a customer would need help deciding?

These items are all content, and they can all lead to a higher conversion rate, which drives revenue for your business. Your product page can be a big contributor to the bottom line if you optimize it well.

Secondary benefits of content that lead to revenue

When you implement a content marketing plan and start creating targeted content that helps your website rank well for more keywords, you raise your site’s overall authority. With a higher DA (domain authority), it’s easier to rank well for your most important keywords.

The content you create to target a handful of long-tail keywords could end up providing the boost your site needs for a critical term. If you can move into one of the top three positions for a super-competitive keyword, you’ll likely see a big increase in natural search traffic.

While this may not be directly attributable to the newly created content in your analytics account, you should be able to tell when you deployed new content, when the rankings increased for the new terms and when the DA increased, allowing the rankings for the core terms to increase. You can show a timeline that helps the team understand how the content you created drove the keyword rank improvement and, in time, the revenue for the site.

When people say it’s too hard to tie revenue to content, don’t listen. It’s not hard if you know how things work and where to find the data. It’s important to show the results of your efforts so that when it’s time to renew the client’s contract or it’s time for your annual review, you can show how much revenue was tied to your efforts.

Not everyone you work with will understand DA gains, keyword rank improvements — while we know from 4 to 1 is huge, someone else may not understand the significance. People always understand dollars. If content drove $1,000 last year and $100,000 this year, and you know how to show them, the meeting should go quite well.

You can drive revenue with content, and you need to talk about how it’s done.

Some opinions expressed in this article may be those of a guest author and not necessarily Marketing Land. Staff authors are listed here.

Go to Source
Author: Rachel Lindteigen

The post How content drives revenue (and how to prove it) appeared first on On Page SEO Checker.


Google now removing medical records from its search results

Google is now purging private medical information from their search results. Bloomberg reported the change in Google’s removal policies, which adds a single line that reads:

Confidential, personal medical records of private people

Google did not give much information to Bloomberg about the change, only telling Bloomberg that they have “confirmed the changes do not affect search advertising.” Google declined to comment further on why they are making this change now.

Google lists very few examples of information they will remove content from their index, including:

  • national identification numbers like US Social Security Number, Argentine Single Tax Identification Number, Brazil Cadastro de pessoas Físicas, Korea Resident Registration Number, China Resident Identity Card and more.
  • bank account numbers.
  • credit card numbers.
  • images of signatures.
  • nude or sexually explicit images that were uploaded or shared without your consent.
  • confidential, personal medical records of private people.

Here is a screen shot of the removal page:

Go to Source
Author: Barry Schwartz

The post Google now removing medical records from its search results appeared first on On Page SEO Checker.


Top 15 smartphone apps becoming a static list owned by Google, Facebook, Apple

mobile apps, phone

A new report from MomentFeed argues that “over 80 percent of consumer time on mobile devices is now spent on the apps, websites and properties” of just five companies: Facebook, Google, Apple, Yelp and Bing. According to comScore, more than 70 percent of consumer digital media time is mobile and mostly app-based.

The MomentFeed assertion is mostly mirrored in comScore’s most recent top 15 apps ranking:

Six companies are represented: Facebook, Google, Apple, Snapchat, Pandora and Amazon. Google and Facebook have nine of the top 15, Apple has three. There is less and less movement; Facebook has had the top mobile app since the day comScore started reporting this list several years ago.

Here’s what the rankings looked like in May 2014:

Twitter and Yahoo are gone, and Snapchat and Amazon are present, but mostly, it’s the same lineup as in the most recent chart.

The story the comScore data and MomentFeed data both tell is one of increasing concentration of consumer attention and power in the hands of a few top platforms: Google, Facebook, Microsoft, Apple and Amazon (although Microsoft doesn’t have any of the top 15 apps). This trend is also reflected on the advertising side, where Morgan Stanley has estimated that the vast majority of digital ad growth is being divided between Google and Facebook.

Go to Source
Author: Greg Sterling

The post Top 15 smartphone apps becoming a static list owned by Google, Facebook, Apple appeared first on On Page SEO Checker.


Sprout Social releases first non-developer bot-building platform for Twitter

Earlier this week, business messaging platform LivePerson announced a version with a built-in bot powered by IBM’s super-intelligent agent, Watson.

The main benefit, LivePerson said, was that this integrated bot could completely resolve as many as half of all user inquiries entirely by itself, without involving an expensive live agent.

Social management platform Sprout Social is taking another approach to automated customer service, with its announcement this week of a Bot Builder developed with Twitter for that platform.

While other developer-intensive bots have populated Twitter, Sprout said this is the first non-developer bot creation platform for that social network.

[Read the full article on MarTech Today.]

Go to Source
Author: Barry Levine

The post Sprout Social releases first non-developer bot-building platform for Twitter appeared first on On Page SEO Checker.


Search Buzz Video Recap: Google Mobile First Index Hints, Google Posts Live, Google Job Search & The SEO Movie

This week in search, we got a bunch more information around the Google mobile first index. Google said if you are planning on moving to an m-dot domain to responsive, do it before the mobile first release. Google isn’t going to release the mobile first index on one specific day. Google Posts are now available for all Google My Business customers. Google released structured data for job search. Google joked they may be messing with the algorithm tracking tools. Google to make your mobile and desktop pages equivalent. Google said moving a site that was hurt by Panda won’t help you. Google said content stitching or quality is not near duplicate content. Google may skip URLs that repeat the same path many times. Google said they do love breadcrumbs trails. Google said checkmarks in titles is spammy. Google said site moves can take 3 months. Google said be careful with the parameter handling tool. If you use the Google Search Console API then make sure to refresh the last day of data. You can now trigger a suggested video clip in Google. Google’s Gary Illyes doesn’t have manual action access. Google launched they local highlight icons and hotel pricing labels. Google has a new fun fidget spinner easter egg. The SEO movie is out, check it out. That was this past week in search at the Search Engine Roundtable.

Make sure to subscribe to our video feed or subscribe directly on iTunes to be notified of these updates and download the video in the background. Here is the YouTube version of the feed:

For the original iTunes version, click here.

Search Topics of Discussion:

Please do subscribe via iTunes or on your favorite RSS reader. Don’t forget to comment below with the right answer and good luck!

Go to Source
Author: (Barry Schwartz)

The post Search Buzz Video Recap: Google Mobile First Index Hints, Google Posts Live, Google Job Search & The SEO Movie appeared first on On Page SEO Checker.


SMX Advanced session: Mobile-First For The Advanced SEO

Mobile First for the Advanced SEO session from SMX Advanced

SMX Advanced was amazing this year, and when they asked me to write up a session, I immediately asked to cover the mobile-first session. Sure, we’ve been talking about being “mobile-first” for years, but with Google’s impending Mobile-First Index (yes, I capitalized that on purpose), I knew this session would be full of awesome info.

Mobile-first audit framework

Leslie To kicked off the session with an in-depth walk-through of a mobile site audit. While there are site elements that matter to users regardless of screen size, To covered the important points that are vital to a successful mobile site. From using HTML5 for videos and rich media to proper navigation menus, she shared a “do” and “don’t” list for each individual element.

There’s a huge difference between having a responsive site and using your responsive site correctly. To pointed out that designers and developers need to allow content and media to scale to fill the screen size of any device, and that it’s important to consider how your site looks on both landscape and portrait device orientations.

Usability isn’t just about your content and scaling, so she also talked about how mobile-friendliness also includes mobile usability. She talked about the correct way to size tap targets, using common gestures, and the importance of coding your site to use the correct contextual keyboard.

To finished up with an explanation of how to audit the different configurations of mobile sites. Whether you’re dealing with a separate mobile URL, a dynamically served mobile site or a responsive site, she showed what to check to ensure each configuration was implemented correctly.

Check out the slides from Leslie To’s presentation:

Mobile sites: How did we get here?

Patrick Stox took the stage next, and he had the audience rolling almost immediately. His presentation covered the history of the telephone, from its invention to today’s smartphone, and how it led us to our current “mobile-first mindset.” Stox was hilarious and informative, stopping in the middle of his brief history of the phone to say that he’d always wanted to present to a room full of people looking at their phones.

After quickly running through the history of the phone, he pointed out that more people in the world have mobile phones than have toilets, and that 68 percent of smartphone users say they check their phone within 15 minutes of waking up the morning. The average consumer checks his or her smartphone 46 times a day — and that’s why it’s important to be mobile-friendly.

With more than 50 percent of web traffic happening on mobile devices and around 60 percent of searches being conducted on mobile, it’s absolutely vital to have a great mobile site, said Stox.

Fifty-three percent of people will leave a page if it takes longer than three seconds to load, so it’s critical that your mobile site loads quickly. Stox then made the case that Google’s Mobile-Friendly Test Tool doesn’t accurately measure load speed; it only checks that mobile site best practices are followed.

To demonstrate, he showed a test he ran on the Washington Post mobile site, which took just over 40 seconds to load. Yet, when you run it through the Mobile-Friendly Test Tool, it passes with flying colors!

Stox then pointed out that most mobile sites out there have fewer links in, fewer links out and less content than their corresponding desktop sites — so we all have a lot of work to do to prepare for the impending Mobile-First Index.

Check out the slides from Patrick Stox’s presentation:

Don’t freak out about the Mobile-First Index

Gary Illyes closed out the session with info on the Mobile-First Index straight from Google’s not-directly-answering-any-questions mouth. He explained that right now, if you’ve got mobile content that isn’t on the desktop site, it won’t show up in Google’s index. After the impending Mobile-First Index rolls out, the opposite will be true — if there’s desktop content that isn’t on your mobile site, it won’t show up in Google’s index.

He told everyone not to freak out, and that there was no set timeline for the rollout of the Mobile-First Index. No clear date was given, but he said the launch was probably many quarters away, and definitely in 2018 at the earliest. Google wants to clearly communicate with publishers before rolling out the update, because they want to be sure that sites are ready for it.

Google understands that there’s much less real estate on a mobile device, so it’s perfectly OK to cut back on unnecessary content (the emphasis is mine). Illyes said that if you want to rank for a term or certain content, it will have to be present on your mobile site.

As part of the discussion about missing content on mobile sites, Illyes pointed out that many images that do really well in Google image searches aren’t present on the corresponding mobile sites, and that will be a problem once the update occurs. He also said that in many cases, rel=canonical markup isn’t even present on mobile sites.

Illyes also pointed out that “mobile-first” literally means “mobile first,” so if there are sites that have no mobile content, the index will fall back and include desktop content. That only holds true for sites with no mobile content, though — once you roll out a mobile site, that’s the only content that gets indexed.

Google knows that the link graph is “completely messed up” on the mobile web, so they’re trying to figure out how to make links work in the Mobile-First Index.

Finally, Illyes pointed out that while the current algorithm devalues content that’s hidden behind “read more” links or accordion tabs, Google understands the constraints of screen real estate on mobile devices. Once the Mobile-First Index is released, content that’s hidden in this manner will still carry its full value.

You can’t check out the slides from Gary Illyes’s presentation, because they were confidential. So instead, here’s one of his fish photos:

Gary's underwater eel shot (since he can't share his slides)

Some opinions expressed in this article may be those of a guest author and not necessarily Search Engine Land. Staff authors are listed here.

Go to Source
Author: Greg Gifford

The post SMX Advanced session: Mobile-First For The Advanced SEO appeared first on On Page SEO Checker.


Search in Pics: Google bathtub table, Bing lunchbox & YouTube stairs

In this week’s Search In Pictures, here are the latest images culled from the web, showing what people eat at the search engine companies, how they play, who they meet, where they speak, what toys they have and more.

Google bathtub table:

Source: Instagram

YouTube stair case with a strong message:

Source: Instagram

Google padded room:

Source: Instagram

Bing lunchbox:

Source: Twitter

Go to Source
Author: Barry Schwartz

The post Search in Pics: Google bathtub table, Bing lunchbox & YouTube stairs appeared first on On Page SEO Checker.


How JavaScript impacts page loading speed on mobile

The effect of JavaScript on mobile web performance is twofold.

One, it is the second largest contributor to webpage weight, behind images, thereby increasing download time; and two, once downloaded, the browser then needs to run the script, which can delay the downloading/rendering of other (perhaps more important) assets on the page.

JavaScript (aka scripts or JS) is one of the triumvirate of technologies that make web pages (and web apps) work. The HTML (Hypertext Markup Language) controls the structure and content of the webpage; CSS (Cascade Styling Sheets) controls how the site looks on different devices; and JavaScript makes the page more interactive and dynamic.

Scripts perform numerous functions on webpages such as loading ads, A/B testing, tag management (personalizing the page) or displaying an inline video player.

Over the last five years, the total weight of pages sent to mobile devices has quadrupled to 2.2MB. Size matters because, in general, the more data that is sent over a mobile, or fixed, network the longer a page will take to load. More data, more seconds staring at an empty mobile screen.

This suggests that images – which tend to take up more of the total kilobytes (KB) or megabytes (MB) of each page – are the main culprit. But this is not always the case.

JavaScript could potentially have more of an impact on page performance than images. As Patrick Meenan, founder of the web performance testing site WebPageTest and software engineer at Google, explains:

“Scripts are usually a (bigger) issue because of the time it takes to actually execute the script in addition to the download size, while images really only matter because of the download size. With mobile devices for example, it can take several seconds to run a script even after it has been downloaded.” 

It’s not necessarily JavaScript, per se, that is the problem, but how it is implemented: scripts can monopolize browser activity, blocking the download and rendering (displaying) of other content.

“The problems are often compounded where the script is referenced in the page. The content after a ‘blocking’ script (as opposed to an async script) doesn’t exist, as far as the browser is concerned, until after the script has been downloaded and executed. When, as is commonly the case, scripts are put at the beginning of the page this means that the page will be completely blank until the scripts have downloaded and executed.”

We will discuss below the difference between blocking, inline, synchronous (sync), asynchronous (async) and deferred scripts and how to fix JavaScript problems, but first we’ll look at how to spot issues.

Testing for blocking JavaScript

If you have tested your webpages using Google PageSpeed Insights (N.B. you should regularly test your mobile webpages using tools such as WebPageTest and PageSpeed Insights), chances are you have seen the following warning:

! Should Fix:

Eliminate render-blocking JavaScript and CSS in above-the-fold content

Your page has 8 blocking script resources and 7 blocking CSS resources. This causes a delay in rendering your page.

None of the above-the-fold content on your page could be rendered without waiting for the following resources to load. Try to defer or asynchronously load blocking resources, or inline the critical portions of those resources directly in the HTML.

Screenshot shows tested with PageSpeed Insights (as detailed in text).

The text and image above is from a Mobile PageSpeed Insights test on conducted in February 2017.

Note “above the fold” refers only to the part of the webpage which is visible on a mobile device, without scrolling, Google is not analyzing scripts on the rest of the page.

The BBC is the world’s most popular English language news website, according to Alexa, so to put it in context we should also test the others in the top four. The results suggests two more publishers have similar issues with JavaScript. (The test also highlights CSS issues, but this is not the focus of the article):

  1. PageSpeed test (8 blocking scripts; 7 blocking CSS resources)
  2. PageSpeed test (0 blocking scripts)
  3. PageSpeed test (2 blocking scripts; 3 blocking CSS resources)
  4. PageSpeed test (6 blocking scripts; 2 blocking CSS resources)

4x growth in JavaScript use in five years

Over the last five years the amount of JavaScript used on the average mobile page has almost quadrupled from 101KB in February 2012 to 387KB in February 2017. The number of requests (a request is the number of times a browser is required to download an additional piece of content or code) for different JavaScript files has increased from 8 to 21.

This is clearly illustrated in the graph below from HTTP Archive. HTTP Archive tests the top 1 million sites several times every month using data from WebPageTest, and publishes trends and stats that are essential benchmarking for the performance of your site.

Graph shows the growth of JavaScript over five years from 101KB in February 2012 to 387KB in February 2017.For the top 1 million sites monitored by HTTP Archive, JavaScript accounts for 17.4% of page weight. JavaScript also accounts for 21 out of 93 total requests (22.6%).

For some sites, particularly in the news space, JavaScript has a considerably larger share of page weight than the norm.

The image below compares the breakdown by content type for the average site with tested by HTTP Archive (15 February 2017):

  • The first thing to note is how impressively small the BBC page size is: 609KB v 2225KB.
  • The second thing to note is how small the combined size of the BBC images: 70KB v 1501KB.
  • The third thing to note is how proportionally large the scripts are: 458KB or 75.2% of total page size.
  • The fourth thing to note (not shown in the charts below) is that 39 (44.3%) of the BBC’s total 88 requests are scripts.

Two pie charts compare the content breakdown of the average mobile site with the BBC. A much larger proportion of the BBC homepage is scripts.

When you compare the test results of the top four English language news websites, it is remarkable how much smaller the BBC is than its rivals. It is a one-third to a half of the size, with two to three times less JavaScript.

  1. tested by HTTP Archive: Scripts 458KB (75.2%) of 609KB of total data; 39 JS requests (44.3%) of 167 88 total requests.
  2. HTTP Archive test: Scripts 1511KB (51%) of 2953KB of total data; 73 JS requests (43.7%) of 167 total requests. (N.B. NY Times has a dedicated mobile site at, which is not listed by HTTP Archive, which may deliver different results.)
  3. HTTP Archive test: Scripts 1183KB (65.7%) of 1802KB of total data; 50 JS requests (47.2%) of 106 total requests.
  4. HTTP Archive test: Scripts 1484KB (68%) of 2182KB of total data; 67 JS requests (31.9%) of 210 total requests.

What is the effect on mobile page speed?

So does it follow that the slim-line BBC site would load much faster than all its rivals?

Err, no. On 15 February 2017, HTTP Archive recorded the following load times:

  1. 18.3 seconds
  2. 27.4 seconds
  3. 8.8 seconds
  4. 31.5 seconds

So, the BBC is faster loading on a mobile device than CNN and the New York Times, but considerably slower than the (larger) ESPN.

This is what the two sites look like on a mobile device. (The filmstrip is one of WebPageTest’s most visually compelling features, easily understood by any non-techie). Each frame represents 1 second. When the HTTP Archive test took place, for 9 seconds mobile visitors saw nothing, while for 4 seconds ESPN visitors saw nothing.The image shows two filmstrips of the and homepages loading on a mobile device.

There could be many reasons why one website might be faster than another, such as server response times, use of content delivery networks (CDN), the impact of ad networks, inclusion of third-party data (common on news sites), or the time and place of the test (in this case California, USA).

However, all other things being equal, it is possible that JavaScript could be a contributing factor. (Apologies for the hedging of bets). As noted above, did receive more warnings for blocking scripts above the fold than the other news sites.

Reducing reliance on JavaScript

JavaScript is often used to perform tasks that cannot (easily) be done with HTML or CSS. As the W3C gradually add these features to the HTML or CSS standards and they are implemented by browsers, the JavaScript patch is no longer needed, as HTML/CSS is likely to be more efficient. A good example of this is responsive images.

Alex Painter, Web Performance Consultant at NCC Group:

“As a rule, it’s worth sticking to the principle of progressive enhancement – delivering a site that works without JavaScript and using scripts only for those extra features that can’t be done any other way.

“Using JavaScript to render content can be expensive – it takes time to load and execute. So, for example, if you can use HTML and CSS to achieve the same result, that’s generally going to be faster.

 “When it comes to responsive images, for example, you can use media queries in CSS and picture/srcset in the HTML to deliver the right image for the viewport without having rely on JavaScript.”

Choose asynchronous and deferred JavaScript over blocking and inline scripts

There are a number of ways that JavaScript can be implemented on a webpage, including:

  1. Blocking scripts are synchronous which means they have to be dealt with immediately and ahead of anything else. By default, all JavaScript is parser blocking. As the browser does not know what the script will do to the page, as soon as it meets a request (in the HTML file) to download a JavaScript file, it stops building the webpage, and does not continue until the file is downloaded and executed.
  1. Inline scripts also stop the page build, but as they are included in the HTML, they do not need to be individually downloaded. However too large or too many inline scripts will bloat and delay the initial download of HTML file.
  1. Asynchronous scripts allows the browser to continue parsing (analyzing the code and building the webpage), while the JavaScript file is downloaded. Including the async attribute in the HTML tells the browser that it doesn’t need to put everything on hold.
  1. Deferred JavaScript – tells the browser to leave the execution of the JS file until after it has finished building the webpage, this is signified with the defer attribute.

Are blocking scripts ever justified?

Patrick Meenan:

“If the site functionality relies on the code, then it needs to be run as a blocking script so that it is ready before the page needs it. A very common case for this is tag managers and A/B testing platforms where the code will change the page. In other cases blocking is used when it will be more work to load the functionality asynchronously.”

Reducing size of JavaScript files

How big is too big? How many requests is too many?

This will always be a balancing act.

Patrick Meenan:

“Since the browser will only load six requests at a time for each domain, if you have more than that it needs to request the rest after the first ones have completed, leading to longer times from the request/response delays.

 “Larger JavaScript files also take longer to parse and run (1ms for every 1KB of uncompressed JS is a reasonable estimate).  All else being equal, if you have the same amount of JS in a lot of files it will take much longer to load than if the same amount of JS was in a single file.”

Google recommends minification of JavaScript files using UglifyJS or Closure Compiler.

For more on how to optimize the speed of your mobile site, check out our previous three-part series:

Andy Favell is Search Engine Watch’s columnist on mobile. He is a London-based freelance mobile/digital consultant, journalist and web editor. Contact him via LinkedInor on Twitter at Andy_Favell.

Related reading

Image shows screenshot of Google Search for Trump – showing three Accelerated Mobile Page articles
A hand holding a white smartphone, with the words 'What can I help you with?' displayed on the screen.

Go to Source
Author: Andy Favell

The post How JavaScript impacts page loading speed on mobile appeared first on On Page SEO Checker.


Google: Moving A Site Won’t Help A Site Impacted By Panda

Google Panda Algorithm

It has been some time since we talked about Panda here and I am sure most of you are happy about that. But since Gary Illyes from Google brought it up yesterday on Twitter, I feel obligated to bring it up here as well – as expected.

Gary said that Panda is part of the core algorithm and because of that, the only way to get your rankings back is to make your site better. He said, moving your site to a new domain or something won’t be enough. Gary wrote “don’t think of Panda as a “penalty”, it’s part of core ranking algo & if you don’t improve the site, a move won’t help you untangle yourself.” He later added that “you need to improve the quality of the site, moving domains will not improve your ranking.”

Here are those tweets:

Honestly, I am not sure what was the trigger for Gary to tweet this, but it is good advice to come from Google anyway.

Ah, it feels good to get a Panda post out…

Forum discussion at Twitter.

Go to Source
Author: (Barry Schwartz)

The post Google: Moving A Site Won’t Help A Site Impacted By Panda appeared first on On Page SEO Checker.


Google: Parameter Handling In Google Search Console Is A Big Gun, Watch Out

Do you use the parameter handling feature within the Google Search Console interface? If so, Google’s Gary Illyes wants you to be careful. He told one webmaster that using that feature is considered not just a hint, but rather it is a directive. He added that using it is also a “big gun” and you should “watch out with it.”

Here is what Gary posted on Twitter:

This tool is used to help you control how Google understands your web site and URLs, espesially for dynamic URLs. To learn more about it, see this Google help document.

The feature has been in Google Search Console since 2009 so it is a solid feature.

Forum discussion at Twitter.

Go to Source
Author: (Barry Schwartz)

The post Google: Parameter Handling In Google Search Console Is A Big Gun, Watch Out appeared first on On Page SEO Checker.


Google: Use The Google Search Console API? Refresh The Last Day Of Data.

This is probably common sense to most of you but if you are using the Google Search Console API it is recommended that you refresh or redownload the previous day of data to make sure you have the most complete set of information. Sometimes the last day of data has incomplete data and the data might still be funneling in, this it is important to make sure your process includes refreshing the last day you have of data.

John Mueller of Google said this on Twitter, “the last day can sometimes include partial data, so if you use it, I’d recommend refreshing your copy next fetch.”

Here is the tweet:

Good practical advice here.

Forum discussion at Twitter.

Go to Source
Author: (Barry Schwartz)

The post Google: Use The Google Search Console API? Refresh The Last Day Of Data. appeared first on On Page SEO Checker.