the new /solutions/ page is actually a single page with a series of called content via JS, which is to count as pages. These pages are noted by the query parameters triggered by using the filter (middle of the page).
GA is only noticing the /solutions/ page and not the corresponding pages b/c the way that AJAX renders and due to the universal tag living in the static portion of the page. We need to ideally find a route to track all unique pages called and any engagement in those sections.
You can use virtual pageview in Google Analytics to track single page application.
This guide describes how to use analytics.js (but you can do it through Google Tag Manager or Tealium too) to measure page activity on sites whose content is loaded dynamically without traditional full page loads:
https://developers.google.com/analytics/devguides/collection/analyticsjs/single-page-applications
Related
I was reading up on ajax and how it empowers us to exchange data with a server behind the scenes and consequently avoid full page reloads. My confusion lies here, I don't really understand what full-page reloads mean. I think it's probably cause I've been working with ajax/react since the start I guess and have not really seen any webpage of mine fully reload when I access stuff from a database or an api.
It'd be great if someone could explain what they are and why did we need them before ajax?
A full page load is where the entire page is downloaded from the server. A page typically consists of several sections: header, footer, navigation, and content. In a classic web application without AJAX, a user clicks on a link to another page, and has to download the full page, even though only the main content is changing. The header, footer, and navigation all get downloaded again even though they don't change.
With AJAX there is the opportunity to only change the parts of the page that will change. When a user clicks on the link, JavaScript loads just the content for that link and inserts it into the current page. The header, footer, and navigation don't need to reload.
This introduces other problems that need attention.
When AJAX inserts new content into the page, the URL doesn't change. That makes it difficult for users to bookmark or link to specific content. Well written AJAX applications use history.pushState() to update the URL when loading content via AJAX.
There are then two paths to get to every piece of content. Users can either load the URL containing that content directly, or load the content into some other page by following a link. Web developers need to test and ensure both work.
Search engines have trouble crawling AJAX powered sites. For best compatibility, you need to employ server side rendering (SSR) or pre-rendering to serve initial content on a page load that doesn't require JavaScript.
Even for Googlebot (which executes JavaScript) care must be taken to make an AJAX powered site crawlable. Googlebot doesn't simulate user actions like clicking, scrolling, hovering, or moving the mouse.
Content needs to appear on page load without any user interaction
You must use <a href=...> links for navigation so that Googlebot can find other pages by scanning the document object model (DOM). For users, JavaScript can intercept clicks on those links and prevent a full page load by using return false from the onclick handler or event.preventDefault() in the click handler.
Quick question: Is it possible to dynamically load content like
<amp-twitter
data-tweetid="611193269532295168"
layout="responsive">
via AJAX into an AMP article?
AFAIK, it is not possible but AMP - LIVE-UPDATING AMPS
a new AMP component that updates page content dynamically without additional navigation or reload: readers looking at an earlier version of the page will simply see new updates as they come in.
The amp-live-list component adds support for publishing live updates to AMP pages as new content becomes available in the source document. This works great for implementing live blogs.
In other words, the AMP runtime will poll the server for updates to the origin document, fetching itself. The server can returns the entire AMP page or parts of it, and the runtime updates the page in-place seamlessly.
You can also check a related SO question can AJAX polling be used with AMP? that discusses how to dynamically load updates for the AMP pages.
Hope this helps.
This question exists in different flavors, but not for AJAX pages.
I use AJAX to pull a single video into my page and I want a custom FB share button for it. Everything I've read so far says that FB pulls the required title and image from meta-tags in the page's < head> section (og:image and og:title).
I've tried to change the meta properties when the AJAX call returns, before rendering the share button. This hasn't worked. It uses the values that were present upon initial page load. I have yet to encounter a single answer to this question.
Are there data attributes I can add to the 'fb-like' div to specify a custom title and image (similar to data-href)?
Danke!
You need an individual URL for each individual piece of content that you want to share. Open Graph objects (and simple shared links “become” such, automatically) are identified by their URL (og:url).
Now if your whole page is built on AJAX, you still need to create such individual URLs somehow – the Facebook scraper tool does not “speak” JavaScript, and relies solely on the OG meta information that the server delivers for any URL it requests.
Since the hash part of an URL is only of relevance client-side (and does not even get send to the server), “typical” AJAX URLs that rely on those to tell the client which piece of content to load in the background are no good here.
So if you want to share two pieces of content (videos) as http://www.example.com/?v=vid1 and http://www.example.com/?v=vid2, then you have to make sure that your server delivers the meta data for each video under its respective URL.
I am busy building a single page website. The basic layout of the page is as follows - one section below the other:
Header & Navigation
Content Section 1 (example about us)
Content Section 2 (example products)
Content Section 3 (example clients)
Footer
Each section will have a small menu inside it to ajax the content for the specific section. So Products section will have a product title menu, once clicked, product details will be ajaxed.
I can do these with normal techniques, but the problem is, I need the site to be SEO friendly, and indexed/crawled by Google.
I've never worked with it before, but history.js looks promising. I've done some testing, but can't find resources for my specific question. I am also open to other suggestions. All Ajaxed content will be separate HTML files - for SEO, hence the use of history.js sounding good to me.
Specific Questions:
As the user scrolls down, passing each different section, the URL should
change appropriately.
The ajaxed content in each section should also change the URL.
Google should be able to crawl the site an index the separate pages.
I can change all of the content in a page with history.js, but is there a way to target my sections, so it only changes the content in my desired sections, instead of all content on the page?
I suggest using backbone.js. Its depending on jquery and underscore.js.
It provides you the following features
MVC architecture
It gives more structure to the client side code
Templating
You can maintain templates in the client side which gives you a more organized code.
URL re writing
Re-write urls on ajax calls. It Helps to develop SEO friendly website.
In my site we have only one default.aspx page and we renders each htm pages into default.aspx. now we have added google anlytics code into each htm pages but google analytics report only shows one page default.aspx in tracking. anyone can help on this how we can track for each page?
Thanks in advance.
Regards,
Sagar
To be more precise, Google Analytics tracking code is a pure JavaScript application. It measures page views by calling the _trackPageview function of the tracker object. Since very likely you embedded the tracking code in your static template (which is absolutely good), the _trackPageview only gets invoked on the document load. Though if your application deals with AJAX calls, you have to take care of reporting that virtual page views back to Analytics as Deviant already pointed out.