Most of the sites made by amateur are weak in attributes that are essential for good user experience especially contents. Haphazard copied contents are common since many web designers do not bother to hire a web content writer or pay for the write up.
Site Maps
Another ignored feature of web development is the site map. Most sites do not have an updated site map embedded and this lacunae is due to negligence by cheap web designers. The site owner have no idea how much they will lose from this negligence and many do not bother. Well if you do not wish to achieve good rankings for high traffic on SERP than it is okay you may be happy with your site being good enough for reference? Well yes if the visitors like it and gain information from and no if they find the site useless.
For large websites it is imperative to have a site map embedded or linked. The purpose of a site map is for facilitating indexing by search engines. The other purpose of a site map is to facilitate the human visitor. Hence both attributes are essential and the search engines include them in their indexing and ranking metrics.
Two most widely used site maps use HTML and XML the first is for humans and search engines as well and the second is for search engines. Those webmasters with no knowledge of programming can use online softwares to download a site map for their site. It is that easy and both HTML and XML site maps can be generated from the tools online.
But site owners and webmasters have to constantly update the site maps for better performance. Hence new URLs should be promptly added and defunct ones removed. There is an option in Google Search Console to constantly inspect the site maps use it. Always check for missing URLS on the site in order for it to be properly indexed and ranked.
Anchor text is a word or a phrase which is used to create a hyperlink.
Example of HTML linking.
<a href="http://www.xyz.com">anchor text</a>
The phrase in red is the anchor text. This is very important for search engine optimization for indexing, and the search engines use to understand what the page is all about. In order to retrieve contextual information and description of the page topic and popularity, the algorithms analyse a number of anchor text besides the link itself.
In order to provide relevant results on SERPs search engines use the anchor extensively. Hence webmaster use popular anchor text for ranking but then this can be manipulated hence the importance of anchor as ranking factor has been diluted. Overuse of anchor for ranking can often result in penalisation or drop in ranking of a website being promoted.
As always keywords are used as anchor text by webmasters. Earlier they used same anchor text again and again to rank the site on that keyword. This does not work anymore. Hence it is better to use minimally naturally occurring words and phrases that describe the page well nothing more.
Search engines have factored hundreds of metrics in their ranking algorithm hence repeated use of anchor is bound to fail.
Contextual inform is deciphered using semantics or correlated words and phrases in anchor and surrounding content.
There are few types of anchor texts:
Exact Match is a phrase that is used after the URL naming. For example if the page is about "website promotion" than that becomes the exact matching phrase similarly "top website promotion" will turn into partial match. Brand names can also be used in hyperlink creation or the link can just be left naked with the linking world.
This article has been picked up for readers...due credit is given to the source linked below.
AMP HTML is a subset of HTML for authoring content pages such as news
articles in a way that guarantees certain baseline performance
characteristics.
Being a subset of HTML, it puts some restrictions on the full set of
tags and functionality available through HTML but it does not require
the development of new rendering engines: Existing user agents can
render AMP HTML just like all other HTML.
Also, AMP HTML documents can be uploaded to a web server and served
just like any other HTML document; no special configuration for the
server is necessary. However, they are also designed to be optionally
served through specialized AMP serving systems that proxy AMP documents.
These documents serve them from their own origin and are allowed to
apply transformations to the document that provide additional
performance benefits. An incomplete list of optimizations such a serving
system might do is:
Replace image references with images sized to the viewer’s viewport.
Inline images that are visible above the fold.
Inline CSS variables.
Preload extended components.
Minify HTML and CSS.
AMP HTML uses a set of contributed but centrally managed and hosted
custom elements to implement advanced functionality such as image
galleries that might be found in an AMP HTML document. While it does
allow styling the document using custom CSS, it does not allow author
written JavaScript beyond what is provided through the custom elements
to reach its performance goals.
By using the AMP format, content producers are making the content in
AMP files available to be crawled (subject to robots.txt restrictions),
cached, and displayed by third parties.
Performance
Predictable performance is a key design goal for AMP HTML. Primarily
we are aiming at reducing the time until the content of a page can be
consumed / used by the user.
In concrete terms this means that:
HTTP requests necessary to render and fully layout the document should be minimized.
Resources such as images or ads should only be downloaded if they are likely to be seen by the user.
Browsers should be able to calculate the space needed by every resource on the page without fetching that resource.
contain a top-level <html⚡> tag (<htmlamp> is accepted as well). 🔗
contain <head> and <body> tags (They are optional in HTML). 🔗
contain a <link rel="canonical" href="$SOME_URL" />
tag inside their head that points to the regular HTML version of the
AMP HTML document or to itself if no such HTML version exists. 🔗
contain a <meta charset="utf-8"> tag as the first child of their head tag. 🔗
contain a <meta name="viewport" content="width=device-width,minimum-scale=1"> tag inside their head tag. It’s also recommend to include initial-scale=1 (1). 🔗
contain a <script async src="https://cdn.ampproject.org/v0.js"></script> tag inside their head tag. 🔗
HTML tags can be used unchanged in AMP HTML. Certain tags have equivalent custom tags (such as <img> and <amp-img>) and other tags are outright prohibited:
Tag
Status in AMP HTML
script
Prohibited unless the type is application/ld+json.
(Other non-executable values may be added as needed.) Exception is the
mandatory script tag to load the AMP runtime and the script tags to load
extended components.
Prohibited. Includes input, textarea, select, option. Notably, button element is allowed.
button
Allowed.
style
Required style tags for adjusting opacity. One additional style tag is allowed in head tag for the purpose of custom styling. This style tag must have the attribute amp-custom. [🔗](https://github.com/ampproject/amphtml/blob/master/spec/#cust)
link
rel values registered on microformats.org are allowed. If a rel value is missing from our whitelist, please submit an issue. stylesheet and other values like preconnect, prerender and prefectch
that has side effects in the browser are disallowed. There is a special
case for fetching stylesheets from whitelisted font providers.
meta
The http-equiv attribute is banned. Otherwise allowed.
a
The href attribute value must not begin with javascript:. If set, the target attribute value must be _blank. Otherwise allowed. [🔗](https://github.com/ampproject/amphtml/blob/master/spec/#ancr)
svg
Most SVG elements are allowed.
Validator implementations should use a whitelist based on the HTML5 specification with the above tags removed. See AMP Tag Addendum.
Comments
Conditional HTML comments are not allowed.
HTML attributes
Attribute names starting with on (such as onclick or onmouseover) are disallowed in AMP HTML. The attribute with the literal name on (no suffix) is allowed.
The style attribute must not be used.
XML-related attributes, such as xmlns, xml:lang, xml:base, and xml:space are disallowed in AMP HTML.
Links
The javascript: schema is disallowed.
Stylesheets
Major semantic tags and the AMP custom elements come with default
styles to make authoring a responsive document reasonably easy. An
option to opt out of default styles may be added in the future.
@-rules
The following @-rules are allowed in stylesheets: @font-face, @keyframes, @media, @supports. @import will not be allowed. Others may be added in the future.
Author stylesheets
Authors may add custom styles to a document using a single <style amp-custom> tag in the head of the document.
Selectors
The following restrictions apply to selectors in author style sheets:
Universal selector
The universal selector * may
not be used in author stylesheets. This is because it can have negative
performance implications and could be used to circumvent the rules set
out in the following paragraph.
not selector
:not() may not be used in selectors because it can be used to simulate the universal selector.
Pseudo-selectors, pseudo-classes and pseudo-elements
Pseudo-selectors, pseudo-classes and pseudo-elements are only allowed
in selectors that contain tag names and those tag names must not start
with amp-.
Example OK: a:hover, div:last-of-type
Example not OK: amp-img:hover, amp-img:last-of-type
Class and tag names
Class names, in author stylesheets, may not start with the string -amp-.
These are reserved for internal use by the AMP runtime. It follows,
that the user’s stylesheet may not reference CSS selectors for -amp- classes and i-amp tags. These classes and elements are not meant to be customized by authors. Authors, however, can override styles of amp- classes and tags for any CSS properties not explicitly forbidden by these components’ spec.
To prevent usage of attribute selectors to circumvent class name
limitations it is generally not allowed for CSS selectors to contain
tokens and strings starting with -amp- and i-amp.
Important
Usage of the !important qualifier is not allowed. This is a necessary
requirement to enable AMP to enforce its element sizing invariants.
Properties
These CSS properties are permanently banned:
behavior
-moz-binding
The following properties are currently blacklisted due to performance concerns:
filter
AMP only allows transitions and animations of properties that can be
GPU accelerated in common browsers. We currently whitelist: opacity, transform (also -vendorPrefix-transform).
In the following examples <property> needs to be in the whitelist above.
@keyframes name { from: {<property>: value} to {<property: value>} } (also @-vendorPrefix-keyframes)
overflow (and overflow-y, overflow-x) may not be styled as “auto” or “scroll”. No user defined element in an AMP document may have a scrollbar.
Maximum size
It is a validation error if the author stylesheet is larger than 50,000 bytes.
Custom fonts
Authors may include stylesheets for custom fonts. The 2 supported
methods are link tags pointing to whitelisted font providers and @font-face inclusion.
Example:
Font providers can be whitelisted if they support CSS-only
integrations and serve over HTTPS. The following origins are currently
allowed for font serving via link tags:
https://fast.fonts.net
https://fonts.googleapis.com
IMPLEMENTERS NOTE: Adding to this list requires a change to the Google AMP Cache CSP rule.
Authors are free to include all custom fonts via a @font-face CSS instruction via their custom CSS. Fonts included via @font-face must be fetched via the HTTP or HTTPS scheme.
AMP runtime
The AMP runtime is a piece of JavaScript that runs inside every AMP
document. It provides implementations for AMP custom elements, manages
resource loading and prioritization and optionally includes a runtime
validator for AMP HTML for use during development.
The AMP runtime is loaded via the mandatory <script src="https://cdn.ampproject.org/v0.js"></script> tag in the AMP document <head>.
The AMP runtime can be placed into a development mode for any page. Development
mode will trigger AMP validation on the embedded page, which will emit the
validation status and any errors to the javascript developer console.
Development mode may be triggered by appending #development=1 to the URL of
the page.
Resources
Resources such as images, videos, audio files or ads must be included into an AMP HTML file through custom elements such as <amp-img>.
We call them managed resources because whether and when they will be
loaded and displayed to the user is decided by the AMP runtime.
There are no particular guarantees as to the loading behavior of the
AMP runtime, but it should generally strive to load resources quickly
enough, so that they are loaded by the time the user would like to see
them if possible. The runtime should prioritize resources currently in
viewport and attempt to predict changes to the viewport and preload
resources accordingly.
The AMP runtime may at any time decide to unload resources that are
not currently in viewport or reuse the resource containers such as
iframes to reduce overall RAM consumption.
AMP Components
AMP HTML uses custom elements called, “AMP components” to substitute built-in resource-loading tags such as <img> and <video> and to implement features with complex interactions such as image lightboxes or carousels.
See the AMP component spec for details about supported components.
There are 2 types of supported AMP components:
Built-in
Extended
Built-in components are always available in an AMP document and have a dedicated custom element such as <amp-img>. Extended components must be explicitly included into the document.
These attributes define the layout of an element. The key goal here is to ensure that
the element can be displayed and its space can be properly reserved before any of the
JavaScript or remote resources have been downloaded.
See the AMP Layout System for details about the layout system.
on
The on attribute is used to install event handlers on elements. The events that are supported depend on the element.
The value for the syntax is a simple domain specific language of the form:
Example: on="tap:fooId.showLightbox"
If methodName is omitted the default method is executed if defined for the element.
Example: on="tap:fooId"
Some actions, if documented, may accept arguments. The arguments defined in the parenthesis in the key=value notation. The accepted values are:
simple unquoted strings: simple-value;
quoted strings: "string value" or 'string value';
boolean values: true or false;
numbers: 11 or 1.1.
Extended components
Extended components are components that do not necessarily ship with
the AMP runtime. Instead they must be explicitly included into the
document.
Extended components are loaded by including a <script> tag in the head of the document like this:
The <script> tag must have an async attribute and must have a custom-element attribute referencing the name of the element.
Runtime implementations may use the name to render placeholders for these elements.
The script URL must start with “https://cdn.ampproject.org” and must follow a very strict pattern of /v\d+/[a-z-]+-(latest|\d+|\d+.\d+).js.
Extended components are versioned via semver.
The version is referenced explicitly (See $ELEMENT_VERSION above) when
loading the component in the URL. It may have the value “latest”.
Changes to the PATCH version component (x in 1.1.x) must strictly
maintain backward compatibility or fix urgent security issues.
AMP documents may only reference versions with one or two components.
Version “1” states “I accept every version of this component with major
version 1”. Version “1.1” states “I accept every PATCH level of 1.1”.
It is now allowed to explicitly reference the PATCH level in the version
string.
Extended templates
Templates render HTML content based on the language-specific template and provided JSON data.
See the AMP template spec for details about supported templates.
Extended templates are not shipped with the AMP runtime and have to be downloaded just as with extended elements.
Extended components are loaded by including a <script> tag in the head of the document like this:
The <script> tag must have an async attribute and must have a custom-template attribute referencing the type of the
template. The script URL must start with “https://cdn.ampproject.org” and must follow a very strict pattern of
/v\d+/[a-z-]+-(latest|\d+|\d+.\d+).js.
The templates are declared in the document as following:
The type attribute is required and must reference a declared custom-element script.
The id attribute is optional. Individual AMP elements discover their own templates. Typical scenario
would involve an AMP element looking for a <template> either among its children or referenced by ID.
The syntax within the template element depends on the specific template language. However, the template language
could be restricted within AMP. For instance, in accordance with the “template” element, all productions have to
be over a valid well-formed DOM. All of the template outputs are also subject to sanitizing to ensure AMP-valid
output.
See documentation for a specific extended template on the syntax and restrictions.
See versioning of custom elements for more details.
Security
AMP HTML documents must not trigger errors when served with a Content Security Policy that does not include the keywords unsafe-inline and unsafe-eval.
The AMP HTML format is designed so that is always the case.
All AMP template elements must go through AMP security review before they can be submitted into AMP repository.
SVG
Currently, the following SVG elements are allowed:
special: “defs” (all children above are allowed here), “symbol”, “use”
aria: “desc”, “title”
As well as these attributes:
“xlink:href”: only URIs starting with “#” are allowed
“style”
AMP document discovery
If AMP documents are alternative representations of a canonical
document, then the canonical document should point to the AMP document
via a link tag with the relation “amphtml”.
Example:
The AMP document itself is expected to point back with its canonical relation to a document that has the “amphtml” relation.
Note, that AMP document may also be linked to directly. The mechanism
described here provides a standardized way for software to discover
whether an AMP version exists for a canonical document.
As mentioned in my earlier blog these are stripped down HTML pages that download fast. This development also highlights the limitation of web design and development technology. The inability to handle heavily loaded pages points towards design limitation. But there are elements that may be necessary or fit the role but nevertheless not suitable for visibility on mobile or smart phones. The AMP should be able to take care of that. Well time will tell.
The AMP pages use what is termed as diet HTML. The Java Script is not allowed but off the shelf script library can be used this enables images to download whence you scroll to the point. This may also be incorporated in many platforms in time to come.
There are lot or restrictions whence building an AMP pages. The rules if not followed will fail the Google validation test. The tool for this test is built in Google browser Chrome.
These pages are designed for fast download and readability and not for interactivity. Thus they can be easily cached, pre loaded and pre rendered. This is amazing and will Google in time to come create AMP version of regular page and present it to the visitors instantly.
Further information can be had from:
ampproject.org – The main project web page, where you'll find a technical intro, tutorial, GitHub repository, and more
dis.tl/amp-pages – Further information on AMPs and how they work
Google may soon incorporate structured data using vocabulary provided by schema.org in its ranking algorithms. By incorporating the markups one can enhance the search friendliness of one's site. The types of format used are JASN-LD which is the latest introduced and is more script friendly . The other formats are RDFa and Microdata.
The schema creates a machine readable language easily understood by the algorithms. The mark up is embedded in HTML documents.
Attribute to define an item is called itemscope while its property is definedas itemprop. Types are defined as itemtypes.
For Local Search
Itemscope is used to define the item that is in this case a person
Schema are html tags that are recognized by all three major search engines Google, Yahoo and Bing. These tags are in reality guide to content pages for search engine and help improve search quality. On Page markup help the search engines to better understand the contents or topics especially in case of large data base driven sites or sites using CMS.
Almost all web masters understand the importance of H1 tag that specify the importance of a particular topic related to the page. But deeper meaning is not delivered by the H1 tag alone.
Hence people may understand the meaning of the word or semantics. But the search engine may not understand the exact meaning often. Hence specifying you web page content using microdata and vocabulary will help in getting better indexing on SERPs.
The HTML tags here simply provide greater and exact meaning of the keyword or web page contents to the search engine. For better understand please click on the link below:
http://schema.org/docs/gs.html#microdata_why
The Schema website offers good information as to the importance of microdata and how to include tags using the vocabulary. .
