Connect with us

SEO

Best Practices to Make It SEO-Friendly

Published

on

Best Practices to Make It SEO-Friendly


The increasing prevalence of React in modern web development cannot be ignored.

React and other similar libraries (like Vue.js) are becoming the de facto choice for larger businesses that require complex development where a more simplistic approach (like using a WordPress theme) won’t satisfy the requirements.

Despite that, SEOs did not initially embrace libraries like React due to search engines struggling to effectively render JavaScript, with content available within the HTML source being the preference.

However, developments in both how Google and React can render JavaScript have simplified these complexities, resulting in SEO no longer being the blocker for using React.

Still, some complexities remain, which I’ll run through in this guide.

On that note, here’s what we’ll cover:

But first, what is React?

Advertisement

React is an open-source JavaScript library developed by Meta (formerly Facebook) for building web and mobile applications. The main features of React are that it is declarative, is component-based, and allows easier manipulation of the DOM.

The simplest way to understand the components is by thinking of them as plugins, like for WordPress. They allow developers to quickly build a design and add functionality to a page using component libraries like MUI or Tailwind UI.

If you want the full lowdown on why developers love React, start here:

Rendering with React, a short history

React implements an App Shell Model, meaning the vast majority of content, if not all, will be Client-side Rendered (CSR) by default.

CSR means the HTML primarily contains the React JS library rather than the server sending the entire page’s contents within the initial HTTP response from the server (the HTML source).

See also  LinkedIn Shares New Insights into the Brand Benefits of Adopting Sustainability Best Practices [Infographic]

It will also include miscellaneous JavaScript containing JSON data or links to JS files that contain React components. You can quickly tell a site is client-side rendered by checking the HTML source. To do that, right-click and select “View Page Source” (or CTRL + U/CMD + U).

Advertisement
Netflix's homepage source HTML

A screenshot of the netlfix.com homepage source HTML.

If you don’t see many lines of HTML there, the application is likely client-side rendering.

However, when you inspect the element by right-clicking and selecting “Inspect element” (or F12/CMD + ⌥ + I), you’ll see the DOM generated by the browser (where the browser has rendered JavaScript).

The result is you’ll then see the site has a lot of HTML:

Lots of HTML

Note the appMountPoint ID on the first <div>. You’ll commonly see an element like that on a single-page application (SPA), so a library like React knows where it should inject HTML. Technology detection tools, e.g., Wappalyzer, are also great at detecting the library.

Editor’s Note

Ahrefs’ Site Audit saves both the Raw HTML sent from the server and the Rendered HTML in the browser, making it easier to spot whether a site has client-side rendered content.

Gif showing Site Audit saves both Raw HTML and Rendered HTML

Even better, you can search both the Raw and Rendered HTML to know what content is specifically being rendered client-side. In the below example, you can see this site is client-side rendering key page content, such as the <h1> tag.

Advertisement

Gif showing site is client-side rendering key page content

Joshua Hardwick

Websites created using React differ from the more traditional approach of leaving the heavy-lifting of rendering content on the server using languages like PHP—called Server-side Rendering (SSR).

Flowchart showing the SSR process

The above shows the server rendering JavaScript into HTML with React (more on that shortly). The concept is the same for sites built with PHP (like WordPress). It’s just PHP being turned into HTML rather than JavaScript.

Before SSR, developers kept it even simpler.

They would create static HTML documents that didn’t change, host them on a server, and then send them immediately. The server didn’t need to render anything, and the browser often had very little to render.

SPAs (including those using React) are now coming full circle back to this static approach. They’re now pre-rendering JavaScript into HTML before a browser requests the URL. This approach is called Static Site Generation (SSG), also known as Static Rendering.

Two flowcharts showing the SSG process

In practice, SSR and SSG are similar.

The key difference is that rendering happens with SSR when a browser requests a URL versus a framework pre-rendering content at build time with SSG (when developers deploy new code or a web admin changes the site’s content).

SSR can be more dynamic but slower due to additional latency while the server renders the content before sending it to the user’s browser.

SSG is faster, as the content has already been rendered, meaning it can be served to the user immediately (meaning a quicker TTFB).

Advertisement

How Google processes pages

To understand why React’s default client-side rendering approach causes SEO issues, you first need to know how Google crawls, processes, and indexes pages.

We can summarize the basics of how this works in the below steps:

  1. Crawling – Googlebot sends GET requests to a server for the URLs in the crawl queue and saves the response contents. Googlebot does this for HTML, JS, CSS, image files, and more.
  2. Processing – This includes adding URLs to the crawl queue found within <a href> links within the HTML. It also includes queuing resource URLs (CSS/JS) found within <link> tags or images within <img src> tags. If Googlebot finds a noindex tag at this stage, the process stops, Googlebot won’t render the content, and Caffeine (Google’s indexer) won’t index it.
  3. Rendering – Googlebot executes JavaScript code with a headless Chromium browser to find additional content within the DOM, but not the HTML source. It does this for all HTML URLs.
  4. Indexing – Caffeine takes the information from Googlebot, normalizes it (fixes broken HTML), and then tries to make sense of it all, precomputing some ranking signals ready for serving within a search result.
Flowchart showing how Google crawls, processes, and indexes pages

Historically, issues with React and other JS libraries have been due to Google not handling the rendering step well.

Some examples include:

  • Not rendering JavaScript – It’s an older issue, but Google only started rendering JavaScript in a limited way in 2008. However, it was still reliant on a crawling scheme for JavaScript sites created in 2009. (Google has since deprecated the scheme.)
  • The rendering engine (Chromium) being out of date – This resulted in a lack of support for the latest browser and JavaScript features. If you used a JavaScript feature that Googlebot didn’t support, your page might not render correctly, which could negatively impact your content’s indexing.
  • Google had a rendering delay – In some cases, this could mean a delay of up to a few weeks, slowing down the time for changes to the content to reach the indexing stage. This would have ruled out relying on Google to render content for most sites.

Thankfully, Google has now resolved most of these issues. Googlebot is now evergreen, meaning it always supports the latest features of Chromium.

In addition, the rendering delay is now five seconds, as announced by Martin Splitt at the Chrome Developer Summit in November 2019:

Last year Tom Greenaway and I were on this stage and telling you, ‘Well, you know, it can take up to a week, we are very sorry for this.’ Forget this, okay? Because the new numbers look a lot better. So we actually went over the numbers and found that, it turns out that at median, the time we spent between crawling and actually having rendered these results is – on median – it’s five seconds!”

This all sounds positive. But is client-side rendering and leaving Googlebot to render content the right strategy?

The answer is most likely still no.

Advertisement

Common SEO issues with React

In the past five years, Google has innovated its handling of JavaScript content, but entirely client-side rendered sites introduce other issues that you need to consider.

It’s important to note that you can overcome all issues with React and SEO.

React JS is a development tool. React is no different from any other tool within a development stack, whether that’s a WordPress plugin or the CDN you choose. How you configure it will decide whether it detracts or enhances SEO.

Ultimately, React is good for SEO, as it improves user experience. You just need to make sure you consider the following common issues.

1. Pick the right rendering strategy

The most significant issue you’ll need to tackle with React is how it renders content.

As mentioned, Google is great at rendering JavaScript nowadays. But unfortunately, that isn’t the case with other search engines. Bing has some support for JavaScript rendering, although its efficiency is unknown. Other search engines like Baidu, Yandex, and others offer limited support.

Advertisement

Sidenote.

This limitation doesn’t only impact search engines. Apart from site auditors, SEO tools that crawl the web and provide critical data on elements like a site’s backlinks do not render JavaScript. This can have a significant impact on the quality of data they provide. The only exception is Ahrefs, which has been rendering JavaScript across the web since 2017 and currently renders over 200 million pages per day.

Introducing this unknown builds a good case for opting for a server-side rendered solution to ensure that all crawlers can see the site’s content.

In addition, rendering content on the server has another crucial benefit: load times.

Load times

Rendering JavaScript is intensive on the CPU; this makes large libraries like React slower to load and become interactive for users. You’ll generally see Core Web Vitals, such as Time to Interactive (TTI), being much higher for SPAs—especially on mobile, the primary way users consume web content.

Overview of metrics' performance, including FCP, LCP, etc

An example React application that utilizes client-side rendering.

However, after the initial render by the browser, subsequent load times tend to be quicker due to the following:

Depending on the number of pages viewed per visit, this can result in field data being positive overall.

Four bar graphs showing positive field data of FCP, LCP, FID, and CLS

However, if your site has a low number of pages viewed per visit, you’ll struggle to get positive field data for all Core Web Vitals.

Advertisement

Solution

The best option is to opt for SSR or SSG mainly due to:

  • Faster initial renders.
  • Not having to rely on search engine crawlers to render content.
  • Improvements in TTI due to less JavaScript code for the browser to parse and render before becoming interactive.

Implementing SSR within React is possible via ReactDOMServer. However, I recommend using a React framework called Next.js and using its SSG and SSR options. You can also implement CSR with Next.js, but the framework nudges users toward SSR/SSG due to speed.

Next.js supports what it calls “Automatic Static Optimization.” In practice, this means you can have some pages on a site that use SSR (such as an account page) and other pages using SSG (such as your blog).

The result: SSG and fast TTFB for non-dynamic pages, and SSR as a backup rendering strategy for dynamic content.

Sidenote.

You may have heard about React Hydration with ReactDOM.hydrate(). This is where content is delivered via SSG/SSR and then turns into a client-side rendered application during the initial render. This may be the obvious choice for dynamic applications in the future rather than SSR. However, hydration currently works by loading the entire React library and then attaching event handlers to HTML that will change. React then keeps HTML between the browser and server in sync. Currently, I can’t recommend this approach because it still has negative implications for web vitals like TTI for the initial render. Partial Hydration may resolve this in the future by only hydrating critical parts of the page (like ones within the browser viewport) rather than the entire page; until then, SSR/SSG is the better option.

Since we’re talking about speed, I’ll be doing you a disservice by not mentioning other ways Next.js optimizes the critical rendering path for React applications with features like:

  • Image optimization – This adds width and height <img> attributes and srcset, lazy loading, and image resizing.
  • Font optimization – This inlines critical font CSS and adds controls for font-display.
  • Script optimization – This lets you pick when a script should be loaded: before/after the page is interactive or lazily.
  • Dynamic imports – If you implement best practices for code splitting, this feature makes it easier to import JS code when required rather than leaving it to load on the initial render and slowing it down.

Speed and positive Core Web Vitals are a ranking factor, albeit a minor one. Next.js features make it easier to create great web experiences that will give you a competitive advantage.

TIP

Many developers deploy their Next.js web applications using Vercel (the creators of Next.js), which has a global edge network of servers; this results in fast load times.

Vercel provides data on the Core Web Vitals of all sites deployed on the platform, but you can also get detailed web vital data for each URL using Ahrefs’ Site Audit.

Advertisement

Simply add an API key within the crawl settings of your projects.

Text field to add API key

After you’ve run your audit, have a look at the performance area. There, Ahrefs’ Site Audit will show you charts displaying data from the Chrome User Experience Report (CrUX) and Lighthouse.

Pie charts and bar graphs showing data from CrUX and Lighthouse

2. Use status codes correctly

A common issue with most SPAs is they don’t correctly report status codes. This is as the server isn’t loading the page—the browser is. You’ll commonly see issues with:

  • No 3xx redirects, with JavaScript redirects being used instead.
  • 4xx status codes not reporting for “not found” URLs.

You can see below I ran a test on a React site with httpstatus.io. This page should obviously be a 404 but, instead, returns a 200 status code. This is called a soft 404.

Table showing URL on left. On right, under "Status codes," it shows "200"

The risk here is that Google may decide to index that page (depending on its content). Google could then serve this to users, or it’ll be used when evaluating a site.

In addition, reporting 404s helps SEOs audit a site. If you accidentally internally link to a 404 page and it’s returning a 200 status code, quickly spotting the area with an auditing tool may become much more challenging.

There are a couple of ways to solve this issue. If you’re client-side rendering:

  1. Use the React Router framework.
  2. Create a 404 component that shows when a route isn’t recognized.
  3. Add a noindex tag to “not found” pages.
  4. Add a <h1> with a message like “404: Page Not Found.” This isn’t ideal, as we don’t report a 404 status code. But it will prevent Google from indexing the page and help it recognize the page as a soft 404.
  5. Use JavaScript redirects when you need to change a URL. Again, not ideal, but Google does follow JavaScript redirects and pass ranking signals.

If you’re using SSR, Next.js makes this simple with response helpers, which let you set whatever status code you want, including 3xx redirects or a 4xx status code. The approach I outlined using React Router can also be put into practice while using Next.js. However, if you’re using Next.js, you’re likely also implementing SSR/SSG.

3. Avoid hashed URLs

This issue isn’t as common for React, but it’s essential to avoid hash URLs like the following:

  • https://reactspa.com/#/shop
  • https://reactspa.com/#/about
  • https://reactspa.com/#/contact

Generally, Google isn’t going to see anything after the hash. All of these pages will be seen as https://reactspa.com/.

Solution

SPAs with client-side routing should implement the History API to change pages.

You can do this relatively easily with both React Router and Next.js.

Advertisement

4. Use <a href> links where relevant

A common mistake with SPAs is using a <div> or a <button> to change the URL. This isn’t an issue with React itself, but how the library is used.

Doing this presents an issue with search engines. As mentioned earlier, when Google processes a URL, it looks for additional URLs to crawl within <a href> elements.

If the <a href> element is missing, Google won’t crawl the URLs and pass PageRank.

Solution

The solution is to include <a href> links to URLs that you want Google to discover.

Checking whether you’re linking to a URL correctly is easy. Inspect the element that internally links and check the HTML to ensure you’ve included <a href> links.

As in the above example, you may have an issue if they aren’t.

However, it’s essential to understand that missing <a href> links aren’t always an issue. One benefit of CSR is that when content is helpful to users but not search engines, you can change the content client-side and not include the <a href> link.

In the above example, the site uses faceted navigation that links to potentially millions of combinations of filters that aren’t useful for a search engine to crawl or index.

Advertisement

List of genres

Loading these filters client-side makes sense here, as the site will conserve crawl budget by not adding <a href> links for Google to crawl.

Next.js makes this easy with its link component, which you can configure to allow client-side navigation.

If you’ve decided to implement a fully CSR application, you can change URLs with React Router using onClick and the History API.

5. Avoid lazy loading essential HTML

It’s common for sites developed with React to inject content into the DOM when a user clicks or hovers over an element—simply because the library makes that easy to do.

This isn’t inherently bad, but content added to the DOM this way will not be seen by search engines. If the content injected includes important textual content or internal links, this may negatively impact:

  • How well the page performs (as Google won’t see the content).
  • The discoverability of other URLs (as Google won’t find the internal links).

Here’s an example on a React JS site I recently audited. Here, I’ll show a well-known e‑commerce brand with important internal links within its faceted navigation.

However, a modal showing the navigation on mobile was injected into the DOM when you clicked a “Filter” button. Watch the second <!—-> within the HTML below to see this in practice:

Gif of modal showing the navigation on mobile was injected into DOM

Solution

Spotting these issues isn’t easy. And as far as I know, no tool will directly tell you about them.

Instead, you should check for common elements such as:

  • Accordions
  • Modals
  • Tabs
  • Mega menus
  • Hamburger menus

You’ll then need to inspect the element on them and watch what happens with the HTML as you open/close them by clicking or hovering (as I have done in the above GIF).

Suppose you notice JavaScript is adding HTML to the page. In that case, you’ll need to work with the developers. This is so that rather than injecting the content into the DOM, it’s included within the HTML by default and is hidden and shown via CSS using properties like visibility: hidden; or display: none;.

Advertisement

6. Don’t forget the fundamentals

While there are additional SEO considerations with React applications, that doesn’t mean other fundamentals don’t apply.

You’ll still need to make sure your React applications follow best practices for:

Final thoughts

Unfortunately, working with React applications does add to the already long list of issues a technical SEO needs to check. But thanks to frameworks like Next.js, it makes the work of an SEO much more straightforward than what it was historically.

Hopefully, this guide has helped you better understand the additional considerations you need to make as an SEO when working with React applications.

Have any questions on working with React? Tweet me.





Source link

SEO

SEO Legend, Mentor & Friend

Published

on

SEO Legend, Mentor & Friend

The SEO industry will be forever changed with the loss of Bill Slawski, owner of SEO By The Sea, Director of Search at Go Fish Digital, educator, mentor, and friend.

Bill was a great many things to a lot of people. He has been a contributor here at Search Engine Journal since 2019, and a friend and mentor to many of us for decades more.

It’s not often you can say that someone has influenced and shaped an entire industry. But this is one of those times.

On May 19, 2022, the SEO industry learned that Bill Slawski had passed away.

The loss and sadness across our community were palpable.

Remembering Bill Slawski: SEO Legend, Mentor & Friend

Remembering Bill Slawski: SEO Legend, Mentor & Friend

Remembering Bill Slawski: SEO Legend, Mentor & Friend

Remembering Bill Slawski: SEO Legend, Mentor & Friend

Remembering Bill Slawski: SEO Legend, Mentor & Friend

Remembering Bill Slawski: SEO Legend, Mentor & Friend
Remembering Bill Slawski: SEO Legend, Mentor & Friend

Remembering Bill Slawski: SEO Legend, Mentor & FriendRemembering Bill Slawski: SEO Legend, Mentor & Friend

A search patent expert, colleague and mentor to many, and a friend to many more, Bill influenced the lives of everyone in the search industry.

Advertisement

If you hadn’t read one of the thousands of articles he wrote or contributed to, watched one of his interviews, attended one of his talks, or listened to a podcast he was a guest on – I guarantee that someone you work with, learn from, or work for has.

This was due in no small part to Bill’s vast knowledge and expertise, combined with an unequaled passion for the nuances and technological advances that make search engines tick.

I spoke with Bill a few weeks ago as we were planning a feature article on the patents he felt are most impactful for search marketers.

In that interview, he explained his love for patents.

“One thing I always say about patents is they’re the best place to find assumptions about searchers, about search, and about the web. These are search engineers sharing their opinions in addition to solving problems,” he said.

He loved getting to see what engineers were thinking, and what they had to say when it comes to different problems on the web.

“One of my favorite types of patents to look up is when they repeat a patent and file a continuation,” Bill explained. “I like to look at these continuation patents and see how they’ve changed, because they don’t tell you, ‘This is what we’re doing.’”

That innate curiosity and true passion for unraveling the complexities of the search algorithms we work with each day made talking with Bill and reading his work a real joy.

Advertisement

I can’t tell you how many times I’ve gone to Bill or referenced his work in mine over the years, as have so many others.

He had a real talent for making complex concepts more accessible for readers and marketers of all stripes. As a result, his contributions to our collective understanding of how search works are unrivaled.

Bill Slawski’s work and knowledge are foundational to the practice of SEO as we know it today.

I speak for all of us at SEJ in saying we’re incredibly grateful for what he generously shared with each of us.

He was a close friend and respected colleague to our founder, Loren Baker, as well.

“Bill Slawski was a true friend of mine in more ways than one. First of all, he was a surprising mentor who helped me out quite a bit early on in my career, even before the days of social media or Search Engine Journal. He was my buddy and workmate,” Loren said.

Loren Baker and Bill Slawski

Loren Baker and Bill Slawski

Bill and Loren worked together for a couple of years and spent a lot of time out in the parking lot in Havre de Grace, Maryland, smoking cigarettes and talking about Google patents.

“If anything, I would say that Bill taught me that there was much more to SEO than just ranking alone,” Loren explained, adding that Bill taught him the importance of incorporating a narrative into all of the work that you do.

Advertisement

“He taught me the ethics and workmanship behind creating a piece of digital art that people will want to read, will want to share, and will ultimately search for and click on–touching their lives,” he said. “I will miss Bill deeply. It’s very difficult losing friends.”

Having started in 1996 and launching SEO By The Sea in 2005, Bill was the go-to source when you wanted to understand how search engines work or how they change the way we search or live our lives.

But it was so much more than that.

Bill was generous with his time and eager to share his knowledge of search, information retrieval, NLP, and other information technology with any and all.

He had a gift for taking complex patents, algorithms, concepts, real-world behavior, and search engines and explaining how the world of search and information retrieval worked in a way that everyone could understand.

Bill seemed to have an instinct for understanding what you knew and didn’t know or where you were confused. He could fill in the gaps without making you feel silly for having asked. Even if it was the millionth time he’d answered that question.

You didn’t have to be an SEO rockstar or an experienced professional, either.

If you didn’t understand something or had questions, he would happily spend hours explaining the concepts and offering (or creating) resources to help. And as many in the industry who encountered Braggadocio can attest to, you always felt like a long-lost friend, even if you had just “met” him in text.

Advertisement

“It’s like when you go to a conference and you’re one of the first people there. And all the seats are still empty and there’s not a lot of discussion going on. That’s what the SEO world was like back then…I remember happening upon an SEO forum and just being a lurker. Just looking at what everybody was talking about and thinking, ‘this is a strange career. I’m not sure I can do this.’ In the end, I did it.

I started out working and promoting a website for a couple friends who started a business. And so helping them succeed in business was a pretty good motivation.” Bill Slawski, cognitiveSEO Talks interview, April 5, 2018

Bill’s wealth of knowledge extended far beyond search, too.

With a Bachelor of Arts in English from the University of Delaware and a Juris Doctor Degree from Widener University School of Law, Bill spent 14 years as a court manager, administrator, technologist, and management analyst with the Superior Court of Deleware.

He loved nature and plants, and the ocean. He loved traveling and search conferences, but he ultimately found peace in nature and took advantage of it often. And he shared it with us all.

Bill pushed everyone to look beyond the headlines and keywords.

He was quick to add words of support and congratulations when someone shared an achievement. He encouraged everyone to explore the possible, to not be intimidated by new things, and to better understand the search ecosystem, not just the technology, so we could better serve our families, communities, colleagues, and clients.

His kindness, generosity, loyalty, and love of the industry knew no bounds.

The King of Podcasts on Twitter

The King of Podcasts on Twitter

Marshall Simmonds on Twitter

Marshall Simmonds on Twitter

Here at Search Engine Journal, Bill was a familiar face on social media and a VIP contributor, but he was much more than that.

Matt Southern, News Writer

One of the things I’ll miss most about Bill Slawski is the outdoor photography he shared on Twitter.

As deeply entrenched as he was in SEO and online marketing, he always took time to step back from the keyboard and admire life’s beauty.

I think that’s something we could all benefit from doing more of.

Roger Montti, News Writer

I knew Bill Slawski for almost 20 years, from the forums and search marketing conferences. He created a stir with all the things he discovered in the patents, which went a long way toward demystifying what search engines did.

What impressed me the most was his generosity with his time and how encouraging he was to me and to everyone. I feel privileged and honored to have been able to call him a friend.

Advertisement

He will be profoundly missed.

Brent Csutoras, Advisor and Owner

So much of our marketing journey has been in understanding not only how something works with Google but what they are trying to accomplish over the coming years so we can be prepared and ready to pivot when needed.

Bill’s work with patents provided valuable insight very few individuals were capable of distilling and yet everyone benefited from.

He was instrumental in getting us to where we are as SEOs and digital marketers today.

Bill Slawski Was A Man Of Quiet Impact

“My first interaction with Bill Slawski was on Kim Krause Berg’s Cre8asite forum. I was trying to learn what SEO was all about, so I just lurked, soaking up knowledge from bragadocchio, Black Knight, Grumpus, Barry Welford, and others. I know that Bill started more 10,000 threads there during his time as one of the admins and one of the first things that struck me was his willingness to patiently share his knowledge. At the time, I had no idea who he was, but it quickly became obvious that he was someone who was worth listening to. ”

~ Doc Sheldon, Facebook

That he was.

Atul Gawande once wrote that life is meaningful because it has a story–one driven by a deep need to identify purposes outside of ourselves and a transcendent desire to see and help others achieve their potential.

Advertisement

This was the very essence of Bill’s life.

Not just in the wealth of unparalleled knowledge and resources he has gifted to us, but in the inspiration, guidance, and encouragement he has instilled in us all. That is his legacy and one that will live on.

It’s been difficult to hit Publish on this piece as I don’t feel anything we share could do that legacy justice.

Search Engine Journal will leave Bill’s library of content here untouched in perpetuity, and we’ve left comments open below for all to share your contributions to this memorial for Bill.

Thank you, Bill, for sharing your intelligence, passion, and knowledge with the SEO community.

You will be sorely missed.

Written in collaboration with Angie Nikoleychuk.

!function(f,b,e,v,n,t,s)
{if(f.fbq)return;n=f.fbq=function(){n.callMethod?
n.callMethod.apply(n,arguments):n.queue.push(arguments)};
if(!f._fbq)f._fbq=n;n.push=n;n.loaded=!0;n.version=’2.0′;
n.queue=[];t=b.createElement(e);t.async=!0;
t.src=v;s=b.getElementsByTagName(e)[0];
s.parentNode.insertBefore(t,s)}(window,document,’script’,
‘https://connect.facebook.net/en_US/fbevents.js’);

Advertisement

if( typeof sopp !== “undefined” && sopp === ‘yes’ ){
fbq(‘dataProcessingOptions’, [‘LDU’], 1, 1000);
}else{
fbq(‘dataProcessingOptions’, []);
}

fbq(‘init’, ‘1321385257908563’);

fbq(‘track’, ‘PageView’);

fbq(‘trackSingle’, ‘1321385257908563’, ‘ViewContent’, {
content_name: ‘memoriam-bill-slawski’,
content_category: ‘news seo’
});

Source link

See also  8 Content Lifecycle Management Stages (And Best Practices)
Continue Reading

DON'T MISS ANY IMPORTANT NEWS!
Subscribe To our Newsletter
We promise not to spam you. Unsubscribe at any time.
Invalid email address

Trending