Connect with us

SEO

A Technical SEO Guide to Advanced Core Web Vitals Optimization

Published

on

A Technical SEO Guide to Advanced Core Web Vitals Optimization


Editor’s note: As 2021 winds down, we’re celebrating with a 12 Days of Christmas Countdown of the most popular, helpful expert articles on Search Engine Journal this year.

This collection was curated by our editorial team based on each article’s performance, utility, quality, and the value created for you, our readers.

Each day until December 24th, we’ll repost one of the best columns of the year, starting at No. 12 and counting down to No. 1. Our countdown starts today with our No. 6 column, which was originally published on April 26, 2021.

This in-depth technical SEO guide on advanced Core Web Vitals by Jamie Indigo was well-received by readers. It’s packed full of information and actionable advice on how to diagnose, measure, and improve site performance in terms of human experience.

Really great work on this, Jamie! We appreciate all the great content you continue to contribute to SEJ.

Enjoy!


Real humans want good web experiences. What does that look like in practice?

Advertisement

Continue Reading Below

Well, one recent study cited by Google in a blog post about Core Web Vitals found that mobile web users only kept their attention on the screen for 4-8 seconds at a time.

Read that again.

You have less than 8 seconds to deliver interactive content and get a user to complete a task.

Enter Core Web Vitals (CWV). These three metrics are designed to measure site performance in human experience. The open-source Chromium project announced the metrics in early May 2020 and they were swiftly adopted across Google products.

How do we qualify performance in user-centric measurements?

  1. Is it loading?
  2. Can I interact?
  3. Is it visually stable?

Fundamentally, Core Web Vitals measure how long it takes to complete the script functions needed to paint the above-the-fold content. The arena for these Herculean tasks is a 360 x 640 viewport. It fits right in your pocket!

Advertisement

Continue Reading Below

This war-drum for unaddressed tech debt is a blessing to a lot of product owners and tech SEO professionals who have been backlogged in favor of new features and shiny baubles.

Is the Page Experience update going to be Mobileggedon 4.0?

Probably not.

But when your page passes CWV assessments, users are 24% less likely to abandon page loads. These efforts benefit every source and medium, and most importantly – real humans.

The Page Experience Update

For all the buzz, CWV will be elements in a ranking signal. Expected to roll out gradually mid-June through August 2021, the Page Experience Ranking will be comprised of:

  1. Core Web Vitals.
  2. Mobile-Friendly.
  3. Safe Browsing.
  4. HTTPS.
  5. No Intrusive Interstitials.

Updated documentation clarifies that the rollout will be gradual and that “sites generally should not expect drastic changes.”

Important things to know about the update:

  • Page Experience is evaluated per URL.
  • Page experience is based on a mobile browser.
  • AMP is no longer required for Top Stories carousels.
  • Passing CWV is not a requirement to appear in Top Stories carousels.

A New Page Experience Report In Search Console

Search Console now includes a Page Experience report. The fresh resource includes backdated data for the last 90 days.

In order for a URL to be “Good,” it must meet the following criteria:

  • The URL has Good status in the Core Web Vitals report.
  • The URL has no mobile usability issues according to the Mobile Usability report.
  • The site has no security issues.
  • The URL is served over HTTPS.
  • The site has no Ad Experience issues, or the site was not evaluated for Ad Experience.

The new report offers high-level widgets linking to reports for each of the five “Good” criteria.

The new report offers high-level widgets linking to reports for each of the 5

Workflow For Diagnosing & Actioning CWV Improvements

First, an important caveat regarding Field vs Lab data.

Advertisement

Continue Reading Below

Field Data is performance data collected from real page loads your users are experiencing in the wild. You may also hear Field Data referred to as Real User Monitoring.

Core Web Vitals assessments and the Page Experience Ranking Signal will use Field Data gathered by the Chrome User Experience Report (Crux).

Which Users Are Part Of The Chrome User Experience Report?

Crux data is aggregated users who meet three criteria:

  1. The user opted-in to syncing their browsing history.
  2. The user has not set up a Sync passphrase.
  3. The user has usage statistic reporting enabled.

Crux is your source of truth for Core Web Vitals Assessment.

You can access Crux data using Google Search Console, PageSpeed Insights (page-level), Public Google BigQuery project, or as an origin-level dashboard in Google Data Studio.

Why would you use anything else? Well, CWV Field Data is a restricted set of metrics with limited debugging capabilities and requirements for data availability.

Advertisement

Continue Reading Below

Why Doesn’t My Page Have Data Available From Crux?

Why Doesn't My Page Have Data Available From Crux?

When testing your page, you may see “The Chrome User Experience Report does not have sufficient real-world speed data for this page.”

This is because Crux data is anonymized. There must be enough page loads to report without the reasonable possibility of the individual user being identified.

Web Core Vitals are best identified using field data and then diagnosed/QAed using lab data.

Advertisement

Continue Reading Below

Lab Data allows you to debug performance with end-to-end and deep visibility into UX. It’s called “lab” as this emulated data is collected within a controlled environment with predefined device and network settings.

You can get lab data from PageSpeed Insights, web.dev/measure, Chrome DevTool’s Lighthouse panel, and Chromium-based crawlers like a local NodeJS Lighthouse or DeepCrawl.

Let’s dive into a workflow process.

1. Identify Issues With Crux Data Grouped By Behavior Patterns In Search Console.

Start with Search Console’s Core Web Vitals report to identify groups of pages that require attention. This data set uses Crux data and does you the kindness of grouping together example URLs based on behavior patterns.

If you solve the root issue for one page, you’re likely to fix it for all pages sharing that CWV woe. Typically, these issues are shared by a template, CMS instance, or on-page element. GSC does the grouping for you.

Focus on Mobile data, as Google is moving to a Mobile-First Index and CWV is set to affect mobile SERPs. Prioritize your efforts based on the number of URLs impacted.

Core Web Vitals Google search console issue groupings.

Click into an issue to see example URLs that exhibit the same behavior patterns.

Advertisement

Continue Reading Below

Save these example URLs for testing throughout the improvement process.

Core Web Vitals Google search console issue groupings with page examples

2. Use PageSpeed Insights To Marry Field Data With Lab Diagnostics.

Once you’ve identified pages that need work, use PageSpeed Insights (powered by Lighthouse and Chrome UX Report) to diagnose lab and field issues on a page.

Remember that lab tests are one-off emulated tests. One test is not a source of truth or a definitive answer. Test multiple example URLs.

Advertisement

Continue Reading Below

PageSpeed Insights can only be used to test publicly available and indexable URLs.

If you’re working on noindex or authenticated pages, Crux data is available via API or BigQuery. Lab tests should use Lighthouse.

3. Create A Ticket. Do The Development Work.

I encourage you as SEO professionals to be part of the ticket refinement and QA processes.

Development teams typically work in sprints. Each sprint includes set tickets. Having well-written tickets allows your development team to better size the effort and get the ticket into a sprint.

In your tickets, include:

User Story
Follow a simple format:

As a < type of user/site/etc >, I want < action > in order to  < goal >.

Eg.: As a performant site, I want to include inline CSS for node X on page template Y in order to achieve the largest contentful paint for this page template in under 2.5 seconds.

Acceptance Criteria
Define when the goal has been achieved.  What does “done” mean? Eg.:

  • Inline any critical-path CSS used for above-the-fold content by including it directly in <head>.
  • Critical CSS (read as: that related to node X) appears above JS and CSS resource links in the <head>.

Advertisement

Continue Reading Below

Testing URLs/Strategy
Include the grouped example URLs you copied down from Search Console. Provide a set of steps for QA engineers to follow.
Think about which tool is used, what metric/marker to look for, and the behavior indicating a pass or fail.

Links To Developer Document
Use first-party documentation when available. Please no fluffy blogs. Please? Eg.:

4. QA Changes In Staging Environments Using Lighthouse.

Before code is pushed to production, it’s often put in a staging environment for testing. Use Lighthouse (via Chrome DevTools or local node instance) to measure Core Web Vitals.

If you’re new to testing with Lighthouse, you can learn about ways to test and testing methodology in A Technical SEO Guide to Lighthouse Performance Metrics.

Keep in mind that lower environments typically have fewer resources and will be less performant than production.

Advertisement

Continue Reading Below

Rely on the acceptance criteria to home in on whether the development work completed met the task given.

Largest Contentful Paint

Represents: Perceived loading experience.

Measurement: The point in the page load timeline when the page’s largest image or text block is visible within the viewport.

Key Behaviors: Pages using the same page templates typically share the same LCP node.

Goal: 75% of page loads achieve LCP in < 2.5 seconds.

Available as: Lab and Field Data.

What Can Be LCP?

The LCP metric measures when the largest text or image element in the viewport is visible.

Possible elements that can be a page’s LCP node include:

  1. <img> elements.
  2. <image> elements inside an <svg> tag.
  3. poster images of <video> elements.
  4. background images loaded via url() CSS function.
  5. Text nodes inside block-level elements.

Expect to see additional elements like <svg> and <video> added in future iterations.

How To identify LCP Using Chrome DevTools

  1. Open the page in Chrome emulating a Moto 4G.
  2. Navigate to the Performance panel of Dev Tools (Command + Option + I on Mac or Control + Shift + I on Windows and Linux).
  3. Hover over the LCP marker in the Timings section.
  4. The element(s) that correspond to LCP is detailed in the Related Node field.

How to identify LCP using Chrome DevTools

What Causes Poor LCP?

There are four common issues causing poor LCP:

Advertisement

Continue Reading Below

  1. Slow server response times.
  2. Render-blocking JavaScript and CSS.
  3. Slow resource load times.
  4. Client-side rendering.

Source issues for LCP are painted in broad strokes at best. Unfortunately, none of the single phrases above will likely be enough to pass along to your dev team with meaningful results.

However, you can give the issue momentum by homing in on which of the four origins is in play.

Improving LCP is going to be collaborative. Getting it fixed means sitting in on dev updates and following up as a stakeholder.

Diagnosing Poor LCP Because Of Slow Server Response Time

Where to look: Crux Dashboard v2 – Time to First Byte (TTFB) (page 6)

Diagnosing Poor LCP Because of Slow Server Response Time

IF you see consistently poor TTFB in your field data, then it’s slow server response time dragging LCP.

Advertisement

Continue Reading Below

How To Fix Slow Server Response Time

Server response time is made of numerous factors bespoke to the site’s technology stack. There are no silver bullets here. Your best course of action is to open a ticket with your development team.

Some possible ways to improve TTFB are:

  1. Optimize the server.
  2. Route users to a nearby CDN.
  3. Cache assets.
  4. Serve HTML pages cache-first.
  5. Establish third-party connections early.

Diagnosing Poor LCP Because Of Render-Blocking JavaScript And CSS

Where to look: Lighthouse (via web.dev/measure, Chrome DevTools, Pagespeed Insights, or nodeJS instance). Each of the solutions below include a relevant audit flag.

How To Fix Render-blocking CSS

CSS is inherently render-blocking and impact critical rendering path performance. By default, CSS is treated as a render-blocking resource.

The browser downloads all CSS resources, regardless of blocking or non-blocking behavior.

Minify CSS.

If your site uses a module bundler or build tool, find the plugin that will systematically minimize the scripts.

Advertisement

Continue Reading Below

Defer non-critical CSS.

The Code Coverage report in DevTools will help you identify which styles are used on the page. If it’s not used on any pages, then remove it entirely. (No judgement, CSS files can quickly bloat into the proverbial junk drawer.)
If the styles are used on another page, make a separate style sheet for those pages which use it to call.

Inline critical CSS.

Include the critical-path CSS used for above-the-fold content (as identified by the Code Coverage report) directly in <head>.

Use Dynamic Media Queries.

Media queries are simple filters that when applied to CSS styles break out the styles based on the types of device rendering the content.

Using dynamic media queries means instead of calculating styles for all viewports, you’re calling and calculating those values to the requesting viewport.

How To Fix Render-Blocking JavaScript

Minify and compress JavaScript files.
You’ll need to work with developers to minify and compress network payloads.

Advertisement

Continue Reading Below

Minification involves removing unneeded whitespace and code. It’s best done systematically with a JavaScript compression tool.

Compression involves algorithmically modifying the data format for performant server and client interactions.

Defer unused JavaScript.
Code splitting chops up large chunks of JS to deliver smaller packages. You can then load those that matter to above-the-fold content first.

Minimize unused polyfills.
Remember how Googlebot was stuck in Chrome 44 for what felt like centuries? A polyfills is a piece of code used to provide modern functionality on older browsers that do not natively support it.

Now that Googlebot is evergreen, it also goes by the name tech debt.

Some compilers have built-in functionalities to remove legacy polyfills.

How To Fix Render-Blocking Third-Party Scripts

Delay it.

If the script does not contribute to above the fold content, use async or defer attributes.

Remove it.

If the script uses an <iframe> in the head, remove it. Contact the vendor for an updated implementation method.

Consolidate it.

Advertisement

Continue Reading Below

Audit third-party script use. Who is in charge of the tool? A third-party tool without someone managing it is also known as a liability.

What value does it provide? Is that value greater than the impact on performance? Can the result be achieved by consolidating tools?

Update it.

Another option may be to reach out to the provider to see if they have an updated lean or asynchronous version. Sometimes they do and don’t tell folks that have their old implementation.

Diagnosing Poor LCP Because Of Slow Resource Load Times

Where to look: Lighthouse (via web.dev/measure, Chrome DevTools, Pagespeed Insights, or nodeJS instance). Each of the solutions below includes a relevant audit flag.

Browsers fetch and execute resources as they discover them. Sometimes our paths to discovery are less than ideal. Other times the resources aren’t optimized for their on-page experiences.

Here are ways you can combat the most common causes of slow resource load times:

Advertisement

Continue Reading Below

  1. Optimize and compress images.
    No one needs a 10MB png file. There’s rarely a use case for shipping a large image file.  Or a png.
  2. Preload important resources.
    If a resource is part of the critical path, a simple rel="preload" attribute tells the browser to fetch it as soon as possible.
  3. Compress text files.
    Encode, compress, repeat.
  4. Deliver different assets based on network connection (adaptive serving).
    A mobile device on a 4G network isn’t likely to need/want/tolerate the loading time of assets ready for an ultra 4K monitor. Use the Network Information API which enables web applications to access information about the user’s network.
  5. Cache assets using a service worker.
    While Googlebot doesn’t execute service workers, a user’s device on a thimble’s worth of network connection certainly will. Work with your development team to leverage the Cache Storage API.

Diagnosing Poor LCP Because Of Client-Side Rendering

Where to look: For one-off glances, view the page source. If it’s a couple of lines of gibberish, the page is client-side rendered.

Elements within a page can be client-side rendered. To spot which elements, compare the initial page source with the rendered HTML. If you’re using a crawler, compare the rendered word count difference.

Core Web Vitals are a way of measuring how effective our rendering strategies are.

All rendering options have the same output (they all build web pages), but CWV metrics measure how quickly we deliver what matters when it matters.

Client-side rendering is rarely the answer unless the question is, “What changes went into production at the same time that organic traffic began to tumble?”

How To Fix Client-Side Rendering

“Stop” really isn’t a useful answer. Accurate, but not useful. So instead:

  1. Minimize critical JavaScript.
    Use code splitting, tree shaking, and inline functions in the head for above-the-fold functionalities. Keep those inline scripts <1kb.
  2. Use server-side rendering.
    By having your servers execute JS elements, you can return fully rendered HTML. Note that this will increase your TTFB as the scripts are executed before your server responds.
  3. Use pre-rendering.
    At build time, execute your scripts and have rendered HTML ready for incoming requests. This option has a better server response time but won’t work for sites with frequently changing inventory or prices.

To be clear: Dynamic rendering is not a solution to client-side rendering. It’s giving the troubles of client-side rendering a friend.

First Input Delay (FID)

Represents: Responsiveness to user input.

Measurement: The time from when a user first interacts with a page to the time when the browser is actually able to begin processing event handlers in response to that interaction.

Key behaviors: FID is only available as field data.

Goal: 75% of page loads achieve FID in <= 100 milliseconds.

Available as: Field Data.

Use Total Blocking Time (TBT) For Lab Tests

Since FID is only available as lab data, you’ll need to use Total Blocking Time for lab tests. The two achieve the same end result with different thresholds.

TBT represents: Responsiveness to user input.

TBT measurement: Total time in which the main thread is occupied by tasks taking more than 50ms to complete.

Goal: <= 300 milliseconds.

Available as: Lab Data.

What Causes Poor FID?

const jsHeavy = true;
    While (jsHeavy) {
        console.log("FID fail")
    }

Heavy JavaScript. That’s it.

Poor FID comes from JS occupying the main thread which means your user’s interactions are forced to wait.

What On-Page Elements Are Impacted By FID?

FID is a way of measuring main thread activity. Before on-page elements can respond to user interaction, in-progress tasks on the main thread have to complete.

Here are some of the most prevalent elements that your user is tapping in frustration:

  1. Text fields.
  2. Checkboxes.
  3. Radio buttons (<input> and <textarea>).
  4. Select dropdowns (<select>).
  5. Links (<a>).

Where to look: To confirm it’s an issue for users look at Crux Dashboard v2 – First Input Delay (FID) (page 3). Use Chrome DevTools to identify the exact tasks.

How To See TBT Using Chrome DevTools

  1. Open the page in Chrome.
  2. Navigate to the Network panel of Dev Tools (Command + Option + I on Mac or Control + Shift + I on Windows and Linux).
  3. Tick the box to disable cache.
  4. Navigate to the Performance Panel and check the box for Web Vitals.
  5. Click the reload button to start a performance trace.
  6. Look for the blue blocks labeled Long Tasks or the red right corner markers in the right-hand corner of tasks. These indicate long tasks that took more than 50ms.
  7. Find the TBT for the page at the bottom of the summary.

How to See TBT Using Chrome Devtools

How To Fix Poor FID

Stop loading so many third-party scripts.

Third-party code puts your performance behind another team’s stack.

You’re dependent on their scripts executing in a succinct, performant manner in order for your side to be considered performant.

Free up the main thread by breaking up Long Tasks.

If you’re shipping one massive JS bundle for every page, there’s a lot of functionalities in that bundle that don’t contribute to the page.

Even though they’re not contributing, each JS function has to be downloaded, parsed, compiled, and executed.

By breaking out that big bundle into smaller chunks and only shipping those that contribute, you’ll free up the main thread.

Check your tag manager.

Out-of-the-box tag deployment of tags fire event listeners that will tie up your main thread.

Tag managers can be long-running input handlers that block scrolling. Work with developers to debounce your input handlers.

Optimize your page for interaction readiness.

Ship and execute those JS bundles in an order that matters.

Is it above the fold? It gets prioritized. Use rel=preload.

Pretty important but not enough to block rendering? Add the async attribute.

Below the fold? Delay it with the defer attribute.

Use a web worker.

Web workers allow JavaScript to run on a background thread rather than the main thread your FID is scored on.

Reduce JavaScript execution time.

If you’re shipping one massive JS bundle for every page, there’s a lot of functionalities in that bundle that don’t contribute to the page.

Even though they’re not contributing, each JS function has to be downloaded, parsed, compiled, and executed.

By breaking out that big bundle into smaller chunks (code splitting) and only shipping those that contribute (tree shaking), you’ll free up the main thread.

Cumulative Layout Shift

Represents: Visual stability.

Measurement: A calculation based on the number of frames in which element(s) visually moves and the total distance in pixels the element(s) moved.

layout shift score = impact fraction * distance fraction

Key behaviors: CLS is the only Core Web Vital not measured in time. Instead, CLS is a calculated metric. The exact calculations are actively being iterated on.

Goal: 75% of page loads have a CLS calculated metric of >0.10.

Available as: Lab and Field Data.

Diagnosing Poor CLS

Where to look: To confirm it’s an issue for users look at Crux Dashboard v2 – Cumulative Layout Shift (CLS) (page 4). Use any tool with Lighthouse to identify the bouncing element(s).

Advanced Core Web Vitals: A Technical SEO Guide

Chrome DevTools will provide greater insights into the coordinates of the excitable element and how many times it moves.

How To See CLS Using Chrome DevTools

  1. Open the page in Chrome.
  2. Navigate to the Network panel of Dev Tools (Command + Option + I on Mac or Control + Shift + I on Windows and Linux).
  3. Tick the box to disable cache.
  4. Navigate to the Performance Panel and check the box for Web Vitals.
  5. Click the reload button to start a performance trace.
  6. Click on the red marker(s) in the Experience section.
  7. Look for the name of the node, highlighting of the node on page, and the coordinates for each time the element moved.

How to See CLS Using Chrome DevTools

What Can Be Counted In CLS?

If an element appears in the initial viewport, it becomes part of the metric’s calculation.

If you load your footer before your primary content and it appears in the viewport, then the footer is part of your (likely atrocious) CLS score.

What Causes Poor CLS?

Is it your cookie notice? It’s probably your cookie notice.

Alternatively, look for:

  1. Images without dimensions.
  2. Ads, embeds, and iframes without dimensions.
  3. Dynamically injected content.
  4. Web Fonts causing FOIT/FOUT.
  5. Chains for critical resources.
  6. Actions waiting for a network response before updating DOM.

How To Fix Poor CLS

Always include width and height size attributes on images and video elements.

It’s as simple as <img src="https://www.searchenginejournal.com/technical-seo-core-web-vitals-guide/402501/stable-layout.jpg" width="640" height="360" /> but also not. Responsive web design saw the decline of height and width declarations. The negative impact of this is pages reflowing once the image appeared on screen.

Best practice is to leverage user-agent stylesheets for systematically declared dimensions based on the image’s aspect ratio.

Reserve space for ad slots (and don’t collapse it).

If you’re a publishing site, you’re never going to win an argument over the negative performance impact of third-party ads.

Instead, identify the largest size ad that could be used in a slot and reserve space. If the ad doesn’t populate, keep the placeholder. The gap is better than a layout shift.

Avoid inserting new content above existing content.

An element shouldn’t enter the fighting arena unless it’s ready to be counted.

Take care when placing non-sticky ads near the top of the viewport.

As a general rule, avoid ads near the top of the page. You’ll likely see those flagged in the new GSC Page experience report.

Preload fonts and critical resources.

A font loading late causes a full flash and re-write.

Preload tells the browser that you would like to fetch it sooner than the browser would otherwise discover it because you are certain that it is important for the current page.

<link rel="preload" href="https://www.searchenginejournal.com/assets/Pacifico-Bold.woff2" as="font" type="font/woff2" crossorigin>

Avoid chains for resources needed to create above-the-fold content.

Chains happen when you call a resource that calls a resource. If a critical asset is called by a script, then it can’t be called until that script is executed.

Avoid document.write()

Modern Browsers support speculative parsing off of the main thread.

Read as: They work ahead while scripts are being downloaded and executed – like reading ahead of assignments in a class. document.write() comes in and changes the textbook. Now that work reading ahead was useless.

Chances are this isn’t the work of your devs. Talk to your point of contact for that “magic” third-party tool.

The Future Of CWV Metrics

Google intends to update the Page Experience components on an annual basis. Future CWV metrics will be documented similarly to the initial signal rollout.

Imagine a world where SEO professionals got notice a year in advance that Panda was coming!

Core Web Vitals are already 55% of your Lighthouse v7 score.

Currently, Largest Contentful Paint (LCP) and First Input Delay (FID) are each weighted at 25%. Cumulative Layout Shift is a meager 5% but we can expect to see these equalize.

Smart money is on Q4 2021 once the Chromium team hones in the metric’s calculation.

As technical SEO pros, we’re able to diagnose and provide solutions for a better user-centric experience. Here the thing – those investments and improvements impact all users.

The ROI can be found in every medium. Every channel.

Organic performance is an overall reflection of site health. Leverage that position as you continue to advocate and iterate. Share what you learn.

Most importantly:

| ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄|
Don’t be afraid to
learn in public
|___________|
(__/) ||
(•ㅅ•) ||
/   づ


2021 SEJ Christmas Countdown:

Image Credits

Featured image: Piscine26/Shutterstock
All screenshots taken by author





Source link

Continue Reading
Comments

SEO

A Complete Google Search Console Guide For SEO Pros

Published

on

A Complete Google Search Console Guide For SEO Pros


Google search console provides data necessary to monitor website performance in search and improve search rankings, information that is exclusively available through Search Console.

This makes it indispensable for online business and publishers that are keen to maximize success.

Taking control of your search presence is easier to do when using the free tools and reports.

What Is Google Search Console?

Google Search Console is a free web service hosted by Google that provides a way for publishers and search marketing professionals to monitor their overall site health and performance relative to Google search.

It offers an overview of metrics related to search performance and user experience to help publishers improve their sites and generate more traffic.

Search Console also provides a way for Google to communicate when it discovers security issues (like hacking vulnerabilities) and if the search quality team has imposed a manual action penalty.

Important features:

  • Monitor indexing and crawling.
  • Identify and fix errors.
  • Overview of search performance.
  • Request indexing of updated pages.
  • Review internal and external links.

It’s not necessary to use Search Console to rank better nor is it a ranking factor.

However, the usefulness of the Search Console makes it indispensable for helping improve search performance and bringing more traffic to a website.

How To Get Started

The first step to using Search Console is to verify site ownership.

Google provides several different ways to accomplish site verification, depending on if you’re verifying a website, a domain, a Google site, or a Blogger-hosted site.

Domains registered with Google domains are automatically verified by adding them to Search Console.

The majority of users will verify their sites using one of four methods:

  1. HTML file upload.
  2. Meta tag
  3. Google Analytics tracking code.
  4. Google Tag Manager.

Some site hosting platforms limit what can be uploaded and require a specific way to verify site owners.

But, that’s becoming less of an issue as many hosted site services have an easy-to-follow verification process, which will be covered below.

How To Verify Site Ownership

There are two standard ways to verify site ownership with a regular website, like a standard WordPress site.

  1. HTML file upload.
  2. Meta tag.

When verifying a site using either of these two methods, you’ll be choosing the URL-prefix properties process.

Let’s stop here and acknowledge that the phrase “URL-prefix properties” means absolutely nothing to anyone but the Googler who came up with that phrase.

Don’t let that make you feel like you’re about to enter a labyrinth blindfolded. Verifying a site with Google is easy.

HTML File Upload Method

Step 1: Go to the Search Console and open the Property Selector dropdown that’s visible in the top left-hand corner on any Search Console page.

Screenshot by author, May 2022

Step 2: In the pop-up labeled Select Property Type, enter the URL of the site then click the Continue button.

Step 2Screenshot by author, May 2022

Step 3: Select the HTML file upload method and download the HTML file.

Step 4: Upload the HTML file to the root of your website.

Root means https://example.com/. So, if the downloaded file is called verification.html, then the uploaded file should be located at https://example.com/verification.html.

Step 5: Finish the verification process by clicking Verify back in the Search Console.

Verification of a standard website with its own domain in website platforms like Wix and Weebly is similar to the above steps, except that you’ll be adding a meta description tag to your Wix site.

Duda has a simple approach that uses a Search Console App that easily verifies the site and gets its users started.

Troubleshooting With GSC

Ranking in search results depends on Google’s ability to crawl and index webpages.

The Search Console URL Inspection Tool warns of any issues with crawling and indexing before it becomes a major problem and pages start dropping from the search results.

URL Inspection Tool

The URL inspection tool shows whether a URL is indexed and is eligible to be shown in a search result.

For each submitted URL a user can:

  • Request indexing for a recently updated webpage.
  • View how Google discovered the webpage (sitemaps and referring internal pages).
  • View the last crawl date for a URL.
  • Check if Google is using a declared canonical URL or is using another one.
  • Check mobile usability status.
  • Check enhancements like breadcrumbs.

Coverage

The coverage section shows Discovery (how Google discovered the URL), Crawl (shows whether Google successfully crawled the URL and if not, provides a reason why), and Enhancements (provides the status of structured data).

The coverage section can be reached from the left-hand menu:

CoverageScreenshot by author, May 2022

Coverage Error Reports

While these reports are labeled as errors, it doesn’t necessarily mean that something is wrong. Sometimes it just means that indexing can be improved.

For example, in the following screenshot, Google is showing a 403 Forbidden server response to nearly 6,000 URLs.

The 403 error response means that the server is telling Googlebot that it is forbidden from crawling these URLs.

Coverage report showing 403 server error responsesScreenshot by author, May 2022

The above errors are happening because Googlebot is blocked from crawling the member pages of a web forum.

Every member of the forum has a member page that has a list of their latest posts and other statistics.

The report provides a list of URLs that are generating the error.

Clicking on one of the listed URLs reveals a menu on the right that provides the option to inspect the affected URL.

There’s also a contextual menu to the right of the URL itself in the form of a magnifying glass icon that also provides the option to Inspect URL.

Inspect URLScreenshot by author, May 2022

Clicking on the Inspect URL reveals how the page was discovered.

It also shows the following data points:

  • Last crawl.
  • Crawled as.
  • Crawl allowed?
  • Page fetch (if failed, provides the server error code).
  • Indexing allowed?

There is also information about the canonical used by Google:

  • User-declared canonical.
  • Google-selected canonical.

For the forum website in the above example, the important diagnostic information is located in the Discovery section.

This section tells us which pages are the ones that are showing links to member profiles to Googlebot.

With this information, the publisher can now code a PHP statement that will make the links to the member pages disappear when a search engine bot comes crawling.

Another way to fix the problem is to write a new entry to the robots.txt to stop Google from attempting to crawl these pages.

By making this 403 error go away, we free up crawling resources for Googlebot to index the rest of the website.

Google Search Console’s coverage report makes it possible to diagnose Googlebot crawling issues and fix them.

Fixing 404 Errors

The coverage report can also alert a publisher to 404 and 500 series error responses, as well as communicate that everything is just fine.

A 404 server response is called an error only because the browser or crawler’s request for a webpage was made in error because the page does not exist.

It doesn’t mean that your site is in error.

If another site (or an internal link) links to a page that doesn’t exist, the coverage report will show a 404 response.

Clicking on one of the affected URLs and selecting the Inspect URL tool will reveal what pages (or sitemaps) are referring to the non-existent page.

From there you can decide if the link is broken and needs to be fixed (in the case of an internal link) or redirected to the correct page (in the case of an external link from another website).

Or, it could be that the webpage never existed and whoever is linking to that page made a mistake.

If the page doesn’t exist anymore or it never existed at all, then it’s fine to show a 404 response.

Taking Advantage Of GSC Features

The Performance Report

The top part of the Search Console Performance Report provides multiple insights on how a site performs in search, including in search features like featured snippets.

There are four search types that can be explored in the Performance Report:

  1. Web.
  2. Image.
  3. Video.
  4. News.

Search Console shows the web search type by default.

Change which search type is displayed by clicking the Search Type button:

Default search typeScreenshot by author, May 2022

A menu pop-up will display allowing you to change which kind of search type to view:

Search Types MenuScreenshot by author, May 2022

A useful feature is the ability to compare the performance of two search types within the graph.

Four metrics are prominently displayed at the top of the Performance Report:

  1. Total Clicks.
  2. Total Impressions.
  3. Average CTR (click-through rate).
  4. Average position.
Screenshot of Top Section of the Performance PageScreenshot by author, May 2022

By default, the Total Clicks and Total Impressions metrics are selected.

By clicking within the tabs dedicated to each metric, one can choose to see those metrics displayed on the bar chart.

Impressions

Impressions are the number of times a website appeared in the search results. As long as a user doesn’t have to click a link to see the URL, it counts as an impression.

Additionally, if a URL is ranked at the bottom of the page and the user doesn’t scroll to that section of the search results, it still counts as an impression.

High impressions are great because it means that Google is showing the site in the search results.

But, the meaning of the impressions metric is made meaningful by the Clicks and the Average Position metrics.

Clicks

The clicks metric shows how often users clicked from the search results to the website. A high number of clicks in addition to a high number of impressions is good.

A low number of clicks and a high number of impressions is less good but not bad. It means that the site may need improvements to gain more traffic.

The clicks metric is more meaningful when considered with the Average CTR and Average Position metrics.

Average CTR

The average CTR is a percentage representing how often users clicked from the search results to the website.

A low CTR means that something needs improvement in order to increase visits from the search results.

A higher CTR means the site is performing well.

This metric gains more meaning when considered together with the Average Position metric.

Average Position

Average Position shows the average position in search results the website tends to appear in.

An average in positions one to 10 is great.

An average position in the twenties (20 – 29) means that the site is appearing on page two or three of the search results. This isn’t too bad. It simply means that the site needs additional work to give it that extra boost into the top 10.

Average positions lower than 30 could (in general) mean that the site may benefit from significant improvements.

Or, it could be that the site ranks for a large number of keyword phrases that rank low and a few very good keywords that rank exceptionally high.

In either case, it may mean taking a closer look at the content. It may be an indication of a content gap on the website, where the content that ranks for certain keywords isn’t strong enough and may need a dedicated page devoted to that keyword phrase to rank better.

All four metrics (Impressions, Clicks, Average CTR, and Average Position), when viewed together, present a meaningful overview of how the website is performing.

The big takeaway about the Performance Report is that it is a starting point for quickly understanding website performance in search.

It’s like a mirror that reflects back how well or poorly the site is doing.

Performance Report Dimensions

Scrolling down to the second part of the Performance page reveals several of what’s called Dimensions of a website’s performance data.

There are six dimensions:

1. Queries: Shows the top search queries and the number of clicks and impressions associated with each keyword phrase.

2. Pages: Shows the top-performing web pages (plus clicks and impressions).

3. Countries: Top countries (plus clicks and impressions).

4. Devices: Shows the top devices, segmented into mobile, desktop, and tablet.

5. Search Appearance: This shows the different kinds of rich results that the site was displayed in. It also tells if Google displayed the site using Web Light results and video results, plus the associated clicks and impressions data. Web Light results are results that are optimized for very slow devices.

6. Dates: The dates tab organizes the clicks and impressions by date. The clicks and impressions can be sorted in descending or ascending order.

Keywords

The keywords are displayed in the Queries as one of the dimensions of the Performance Report (as noted above). The queries report shows the top 1,000 search queries that resulted in traffic.

Of particular interest are the low-performing queries.

Some of those queries display low quantities of traffic because they are rare, what is known as long-tail traffic.

But, others are search queries that result from webpages that could need improvement, perhaps it could be in need of more internal links, or it could be a sign that the keyword phrase deserves its own webpage.

It’s always a good idea to review the low-performing keywords because some of them may be quick wins that, when the issue is addressed, can result in significantly increased traffic.

Links

Search Console offers a list of all links pointing to the website.

However, it’s important to point out that the links report does not represent links that are helping the site rank.

It simply reports all links pointing to the website.

This means that the list includes links that are not helping the site rank. That explains why the report may show links that have a nofollow link attribute on them.

The Links report is accessible  from the bottom of the left-hand menu:

Links reportScreenshot by author, May 2022

The Links report has two columns: External Links and Internal Links.

External Links are the links from outside the website that points to the website.

Internal Links are links that originate within the website and link to somewhere else within the website.

The External links column has three reports:

  1. Top linked pages.
  2. Top linking sites.
  3. Top linking text.

The Internal Links report lists the Top Linked Pages.

Each report (top linked pages, top linking sites, etc.) has a link to more results that can be clicked to view and expand the report for each type.

For example, the expanded report for Top Linked Pages shows Top Target pages, which are the pages from the site that are linked to the most.

Clicking a URL will change the report to display all the external domains that link to that one page.

The report shows the domain of the external site but not the exact page that links to the site.

Sitemaps

A sitemap is generally an XML file that is a list of URLs that helps search engines discover the webpages and other forms of content on a website.

Sitemaps are especially helpful for large sites, sites that are difficult to crawl if the site has new content added on a frequent basis.

Crawling and indexing are not guaranteed. Things like page quality, overall site quality, and links can have an impact on whether a site is crawled and pages indexed.

Sitemaps simply make it easy for search engines to discover those pages and that’s all.

Creating a sitemap is easy because more are automatically generated by the CMS, plugins, or the website platform where the site is hosted.

Some hosted website platforms generate a sitemap for every site hosted on its service and automatically update the sitemap when the website changes.

Search Console offers a sitemap report and provides a way for publishers to upload a sitemap.

To access this function click on the link located on the left-side menu.

sitemaps

The sitemap section will report on any errors with the sitemap.

Search Console can be used to remove a sitemap from the reports. It’s important to actually remove the sitemap however from the website itself otherwise Google may remember it and visit it again.

Once submitted and processed, the Coverage report will populate a sitemap section that will help troubleshoot any problems associated with URLs submitted through the sitemaps.

Search Console Page Experience Report

The page experience report offers data related to the user experience on the website relative to site speed.

Search Console displays information on Core Web Vitals and Mobile Usability.

This is a good starting place for getting an overall summary of site speed performance.

Rich Result Status Reports

Search Console offers feedback on rich results through the Performance Report. It’s one of the six dimensions listed below the graph that’s displayed at the top of the page, listed as Search Appearance.

Selecting the Search Appearance tabs reveals clicks and impressions data for the different kinds of rich results shown in the search results.

This report communicates how important rich results traffic is to the website and can help pinpoint the reason for specific website traffic trends.

The Search Appearance report can help diagnose issues related to structured data.

For example, a downturn in rich results traffic could be a signal that Google changed structured data requirements and that the structured data needs to be updated.

It’s a starting point for diagnosing a change in rich results traffic patterns.

Search Console Is Good For SEO

In addition to the above benefits of Search Console, publishers and SEOs can also upload link disavow reports, resolve penalties (manual actions), and security events like site hackings, all of which contribute to a better search presence.

It is a valuable service that every web publisher concerned about search visibility should take advantage of.

More Resources:


Featured Image: bunny pixar/Shutterstock





Source link

Continue Reading

SEO

New Updates To Google Page Experience Scoring Revealed At SEODay

Published

on

New Updates To Google Page Experience Scoring Revealed At SEODay


In an online session at SEODay 2022, Google Search Advocate John Mueller spoke about the impact of page experience on search engine rankings and changes to how the search engine scores sites.

One of the changes revealed was that Google now bases desktop search results on a site’s desktop experience – and mobile search results on a site’s mobile experience.

He also discussed the three primary metrics the search engine uses in determining experience scores: largest contentful paint (LCP), first input delay (FID), and cumulative layout shift (CLS).

“This is not a tie-breaker,” Mueller said. “It won’t make or break your website in terms of search, but it is a factor that comes into play in regards to ranking between different results.”

Google has also added a new page experience metric, “interactivity to next page,” or INP.

Google initially announced INP at I/O 2022, and while Mueller was clear that it is not a direct rankings factor, he discussed INP  as something that may play a role in the future.

Search Console Insights Provides Easier Way To Track Search Rankings

Mueller spent the first part of his presentation discussing the benefits of Search Console Insights. Using Search Console data, alongside analytics, users can generate custom reports and get a different view of the data.

He specifically mentioned using BigQuery and Data Studio as “a way of connecting different data sources together and creating really fancy reports.”

Google is also working on expanding its Search Console APIs, Mueller said, which will allow users to connect these APIs to code on their sites.

Possible uses Mueller mentioned include monitoring top queries and checking to see if specific URLs are indexed.

Videos & Images Take On More Prominent Role In Search

At I/O earlier this year, Google previewed a set of video reports coming to Search Console: a response to a growing appetite for this type of media in search results.

“We see that people love videos and authentic images in search results, so we try to show them more,” Mueller said.

In this growing trend, he included web stories, a collection of pages that often have videos. To facilitate their use, Google now offers a WordPress plugin for creating them.

Authentic Product Reviews Factored Into Rankings

Ecommerce has been trending upward, with the global market expected to surpass $5.5 trillion this year. In its algorithm, Google includes what Mueller termed “authentic reviews” to accommodate digital shoppers better.

“People have high expectations of reviews they find online, so we’ve also worked specifically on updates to algorithms with regards to ranking these product reviews,” he said.

Other Updates From Mueller

At SEODay, Mueller said Google has slightly changed its terminology, with the term “title links” now being used to refer only to the title of a search result.

The search engine giant has also added a new robots meta tag, “indexifembedded.”

Users can leverage the meta tag when embedding content on the main page and want to control the indexing of that embedded piece of content.

Mueller also said Google’s blog was the best source of information on any SEO-related topic.

“With any kind of bigger update… it’s sometimes really tricky to tell folks what they should be looking at specifically,” he noted. “So we have a fairly comprehensive blog post .”


Featured Image: BestForBest/Shutterstock





Source link

Continue Reading

SEO

Making Python Scripts Work In Browser For Web App Creation

Published

on

Making Python Scripts Work In Browser For Web App Creation


Making Python Scripts work in a web browser involves handling web app functions inside a web page via Python Programming Language.

Since JavaScript is the main programming language for making a web browser work, and a web page interactive, Python is usually used for data science, machine learning, and artificial intelligence.

Even if we have back-end infrastructures like Django, and Flask, or static-site-generators like Jekyll, Python is usually behind JavaScript for web development.

But thanks to the latest improvements, JavaScript’s future is open to discussion. “PyScript” allows Python Scripts to work easily within web components.

According to PyScript.net:

“PyScript is a framework that allows users to create rich Python applications in the browser using HTML’s interface and the power of PyodideWASM, and modern web technologies. The PyScript framework provides users at every experience level with access to an expressive, easy-to-learn programming language with countless applications.

In this column, you’ll learn what PyScript is, see an example, learn about alternatives, and also find how to create a custom web app with Python and PyScript.

What Is The JavaScript To Python Migration?

Python is a human-readable programming language.

Thus, there are many Python intermediary program languages to help JavaScript and Java modules and packages are being used in the Python environment.

For example, “TensorFlow” is mainly a JS Package, or Plotly and Selenium.

There are even special packages to make JavaScript code turn into Python code, such as Js2Py.

Why is understanding JavaScript behind Python important?

Because using Python Scripts inside the web browser doesn’t mean that the age of JavaScript is ending for web development.

JavaScript is still functioning behind the Python Scripts in the web browser.

What Is PyScript & How Can You Use It For Creating Web Applications?

PyScript is a framework for making web browsers use Python Scripts.

PyScript turns Python code blocks into Javascript equivalents behind the scenes.

To use PyScript inside a web browser, follow these steps.

Use the stylesheet and JavaScript in the <head> area of the HTML File.

<link rel="stylesheet" href="https://pyscript.net/alpha/pyscript.css" />

<script defer src="https://pyscript.net/alpha/pyscript.js"></script>
  • Use the Python Code inside the “<pyscript></pyscript>” web component.
  • Pay attention to the indentation.
  • Do not format the Python code inside the “<pyscript/>” web component.
  • Use the shortcuts and arguments of the PyScript for importing Python modules and packages.
  • Use the CSS Classes and IDs to insert the results into the HTML Documents’ specific Div.

An Example Of Running Python Script Inside Of Web Browser

An example of running a Python script in the browser is below.

<html>
<head>
     <link rel="stylesheet" href="https://pyscript.net/alpha/pyscript.css" />
     <script defer src="https://pyscript.net/alpha/pyscript.js"></script>
     <link href="https://cdn.jsdelivr.net/npm/bootstrap@5.1.3/dist/css/bootstrap.min.css" rel="stylesheet"
          crossorigin="anonymous">
     <py-env>
- numpy
- matplotlib
     </py-env>
</head>

The <head> area of the HTML File represents the most important resources.

We used the “pyscript.css” and “pyscript.js.”

We also used the “<py-env/>” web component to make the Python modules to be imported.

In this example, we have imported the “numpy” and “matplotlib.”

In the “<body>” section, we will use these modules to create a Python Line Plot inside a web browser.

<body>
     <h1>Let's plot random numbers</h1>
     <div id="plot"></div>
     <py-script output="plot">

At the beginning of the <body>, we used a “div” with the “plot” ID.

It is necessary for making the Python script’s output insertion.

The “<py-script output=”plot”>” is necessary to match the specific HTML Div’s ID value.

 import matplotlib.pyplot as plt

 import numpy as np
 
 x = np.random.randn(1000)

 y = np.random.randn(1000)

 fig, ax = plt.subplots()
 ax.scatter(x, y)
 fig
     </py-script>
</body>
</html>

The Python Script above is a simple line plot script. And you can see the result below.

Screenshot by author, June 2022

The example above shows how to create a line plot with the help of PyScript.

How To See The Terminal Output Of The PyScript

For every Python Script, there is always a terminal that works and outputs the messages from the computation process.

Pyscript ConsoleScreenshot by author, June 2022

The browser console should be read and followed by the developer to see how the PyScript works and what happens behind the scenes.

For example, the screenshot above shows the running process of the Python script that we have created.

It explains how the “numpy”, or “matplotlib” and their dependencies are loaded, and used by which resource.

How To Create a Custom Web App With Python And PyScript?

To create a custom Web App with Python and PyScript, follow these steps:

  • Import the necessary JS and CSS files from PyScript.
  • Create an HTML Document with proper HTML Tag syntax.
  • Use the “py-script” HTML tag with the “output” attribute.
  • Use an HTML Div with a specific ID to match the “output” attribute value.
  • Use “py-env” for the non-built-in libraries of Python.
  • Insert Python Script inside the “py-script” tag without syntax and indentation error.
  • Use “return” in a Python function, or “print” to end your script.
  • Refresh the web page to see the results.

An example of a Custom Python Web App for “random password generation” based on the given password length is below.

Python Web App CreationScreenshot by author, June 2022

The screenshot above demonstrates an example of PyScript in an HTML Document to generate custom passwords.

The Python script that I used is below.

import string
import random
characters = list(string.ascii_letters + string.digits + "!@#$%^&*()")
def generate_random_password():
    length = int(input("Enter password length: "))
    random.shuffle(characters)
    password = []
    for i in range(length):
        password.append(random.choice(characters))
    random.shuffle(password)
    print("".join(password))
generate_random_password()

And, the live version of the custom Python Web App is here.

Just write a numeric value into the input area.

Input AreaScreenshot by author, June 2022

And, it will give you a simple 45-character password.

SEJ Custom Python AppScreenshot by author, June 2022

You can use this technology for some of my other SEJ Articles for auditing sitemaps, or visualization of hot topics from news websites.

Or, in the future, we can demonstrate more sophisticated web apps via PyScript.

What Are The Disadvantages Of PyScript?

The main disadvantage of PyScript is the lack of support.

PyScript is announced during Pycon 2022 to Python developers.

It was a big and exciting event, but community expectations were higher than the current state of PyScript.

Due to weak community support, PyScript development might be slower in the future, but when we think of the journey of Python, it is not surprising.

Python wasn’t that popular until the last five years, because it wasn’t known.

Python Search TrendsScreenshot by author, June 2022

Above, you can see how Python suppressed the search demand of JavaScript overall.

The main reason for Python’s popularity growth is the “pandas” library.

That’s why, ML and Data Science are the main focuses of Python, but it doesn’t have to continue in that way.

Thus, PyScript should be taken into serious consideration for the future of web development.

Pyscript Search DemandScreenshot by author, June 2022

What Are The Alternatives To PyScript?

Alternatives to PyScript are not equivalent to PyScript since it directly runs on the browser, but still, there are different methods to use Python scripts inside a website indirectly.

These included “brython”, “pyodide”, “Appwrite”, “django-readers”, “appdeamon”.

Some alternatives to PyScript are for Firebase such as Appwrite, and some other work for Web Development such as Brython.

Bryhthon for Web App Creation

Brython is older than Pyscript, and it focuses on making Python the primary language for web development with “text/python” file type instead of “text/javascript”.

Can PyScript And Brython Affect Search Engines And SEO?

Yes, in the future, PyScript and Brython can increase their effect on the web development industry.

Changing web development technologies and industries affect search engine crawlers and protocols.

If a search engine starts to see “text/python” files, or “.py” scripts in the HTML source code, it should be able to make it work to see the web page as is.

At the moment, PyScript works via JavaScript, and Brython is already at the beginning of its journey despite its being older.

Other PyScript alternatives work via Node.js like back-end programming libraries, or Firebase like cloud-based systems.

Thus, in the future, Google, as a heavily Python-coded search engine, might need to render Python files for crawling and rendering web pages.

Conclusion For Python As Web Scripting

For people who love coding, it doesn’t matter whether you use Python or JavaScript for a certain task.

But, Python is the easiest programming language to learn as human-readable, it gives more functionality with fewer characters.

Most data scientists and ML (machine learning) Engineers know Python in a good way, and transferring their talents into web development would be similar to the unification of two different universes.

More resources:


Featured Image: TippaPatt/Shutterstock





Source link

Continue Reading

Trending

Copyright © 2021 Liveseo.com