Welcome to
the up and coming age of SEO. Say hello to Siri, Alexa, and Cortana. The quick adoption
of tech savvy speakers given way to new searching behavior, known as
conversational search. Web search inquiries have gotten longer and casual,
similar to natural dialog.
As a result
of this behavior, we need to reconsider the manner in which we compose our content.
Conversational search inquiries are normally offered as conversation starters,
for example, “Where’s a close by café that serves bagels and tea?”
and “Do they have chai?” These inquiries are exact and require
precise answers. Therefore, we have by and by observed an ascent in our SEO
customers, explicitly those searching for schema development to support voice
search.
As reported
by a 2018 BrightLocal study, smart speaker users generally operate their
gadgets to perform local business-related searches weekly. Over 50% of smart speaker users do
this sort of voice command daily! Voice search optimization needs to be included in the ongoing
tasks of search engine strategy. It must to be a piece of an inclusive on-Page
or on-SERP optimization plan or Local Search strategy.
Google will identify insecure sites in the Chrome browser beginning mid-Summer.
Google Chrome SSL in July 2018
Earlier this year, the company announced its Speed Update set to roll out in July, and recently has also announced it will then also mark all sites that have not migrated to HTTPS as “not secure.”
Google has confirmed a date of “early July 2018” as the start date. They have also disclosed how they will alert web surfers of the non-HTTPS status, or not secure.
Sites that remain on the HTTP non-secure protocol will be flagged with a warning in the URL bar of the surfer’s browser.
The non-secure flag will be built into the release of Chrome 68, which will be ready for download in early July.
You and your customers will be able to see the “not secure” text in the address bar of the Chrome browser. Mobile browsers may display the message differently. In either case, the results might cause your site visitors some concern.
There are some additional benefits to securing your site as Google is providing some small rankings boosts.
Depending upon the size of a site and scope of the project, a migration from HTTP to HTTPS can be quite an undertaking. Rest assured there are processes on making this change on your site(s), along with resources for validation and dealing with mixed content issues.
What Is An SSL Certificate?
An SSL certificate is a security certificate that once installed on a web server activates a secure connection between the browser the surfer is viewing the content on and the web server that the content is derived from initially.
The website’s URL protocol will change from HTTP to HTTPS. Currently, a security padlock will also be present in the URL as a way to further signal the status of the website’s Google SSL certificate.
SSL certificates help the web cut down on instances of cybercrime that are often performed through security loopholes in web browsers.
If the connection between the surfer’s web browser and web server are not secure through an SSL connection, a moderately skilled hacker could seize information, such as credit card numbers, as it is being typed into a form on an unsecured website.
Information and Communication Standard Guide from the Ontario Government website
What is AODA?
The Accessibility for Ontarians with Disabilities Act (AODA) is a provincial legislation that ensures those who suffer from any type of disability do not experience barriers, discrimination, or difficulty with their day-to-day experiences. More details about the AODA can be found at this website..
How will it impact by website?
Under the Accessibility for Ontarian with Disabilities Act, all private and non-profit organizations with 50 or more employees and all public sector organizations will need to make their websites accessible.
Beginning January 1, 2014:
If you launch a new public website or your existing site undergoes a significant refresh, the site and any of its web content published after January 1, 2012, must conform to the World Wide Web Consortium Web Content Accessibility Guidelines (WCAG) 2.0, Level A.
What is WCAG Level A or AA?
WCAG 2.0 is an internationally accepted standard for web accessibility developed by the World Wide Web Consortium (W3C), an international team of experts.
WCAG sets out guidelines for organizations to make their websites more accessible. The guidelines cover things like:
[starlist]
writing web content in clear language
providing alternate text for images, or
making sure someone can navigate your website with just a keyboard.
[/starlist]
Each guideline has three levels of accessibility: A, AA and AAA. Level AAA is the highest level of accessibility.
Try the AODA Compliance Wizard. It will help you find out what you have to do to comply with Ontario’s accessibility law. It’s free and will take you less than five minutes to complete. Click Start and answer a few questions about your organization. When you are finished, the Wizard will give you a personalized summary of what you have to do.
W3C Provides a Markup Validation Service. It’s a free service which provides basic analysis of your website. Be aware that this validating tool will report results that are not required for AODA compliance. This is a tool for Web Developers to help make your website WCAG compliant. Remember Validation is just one of the success criterion that is specified in the entire WCAG standard. Your website must be manually assessed and also tested using assistive technology.
Twitter recently announced that they will be changing the way that they allow people to use the information in their tweets.
Check with your Developer or Website Administrator to make sure your Twitter feed continues to function after March 2013. Please take the following steps to make sure your Tweets continue working on your website:
Step 1:
Go to the My applications page on the Twitter website to set up your website as a new Twitter ‘application’. You may need to log-in using your Twitter user name and password.
Step 2:
If you don’t already have a suitable ‘application’ that you can use for your website, set one up on the Create an Application page.
It’s normally best to use the name, description and website URL of the website where you plan to use the Twitter feed.
You don’t need a Callback URL.
Step 3:
After clicking Create your Twitter application, on the following page, click on Create my access token.
Step 4:
Copy the Consumer key, Consumer secret, Access token and Access token secret from your Twitter application page into the settings in your Twitter widget.
Step 5:
Click on Save Changes. If there are any problems, you will get an error message from Twitter which should help diagnose the problem.
