#spent most of the day fixing tags and creating a navigation page which i LOVE and will hopefully be easier to use

[sweetsouldhavernas]

.

[princehcmlet]

Hi Guppy! I'm May, an Admin for CHVRCHESrp. Would you be willing to give us an opinion? Thank you for your consideration!

I’d be glad to give you an opinion, May! DISCLAIMER - everything said in this is just an opinion, if something seems insensitive I’m just trying to give my opinion honestly. Alright, let’s start with the icon (which I can see as the favicon on the blog). From what I can make out it is a wing with text over it. I think that you could take out the overlaying bar of text, and just write the initial of “churches” as a “C” in a dark colored, bold text over the wing. This would make icon much more simple and clear up what it is. Now for the main theme, I like how simple it is, but the detail of the church in the header, and the white, gray, red color scheme makes it feel heavenly or even hellish with the red. The only thing that bothers me is the embossed stroke effect and the transparent red. I would prefer, personally, for it to be a darker, straight, non-embossed stroke that is closer to the maroon you have set as an incorporation of you color scheme already. Red is such a difficult color to work with in graphics, and it looks a lot more professional and beautiful (to me at least) when it is a darker maroon/deep red, and when it is not embossed out. Otherwise, the theme is very organized, I think you could shorten your timeline (even though it does show each of the milestones of the story, maybe there could be a better location where they’re listed?), this also applies for the event dates, because it goes all the way back to 2016, which it’s always nice to update and keep things tidy with spring cleaning. You could always create an archive sideblog that has a page of events and what occured, the progression of the storyline, and leave the main to the most current updates and upcoming/past events? 

For now I’ll be talking more about the plot of the rp, the organization of information, and pages that contribute to that. Your navigation is very well put together, and I think all the links are very fitting. It allows players to click through links for every step of the rp. Now to touch on the plot, which I love that you’ve separated it into seasons. It gives a full detail of what has happened, and lets new players in on what’s happened in the past. While the plot is very interesting and full of details, it does feel a bit diluted. By that, I mean that there are so many details and characters to keep track of that by the end I had more questions than answers. I think maybe before the plot (in another tab section) you could have a list of terms, people, and character information that is important to understand the plot. For example, it would’ve helped to clear up if Lucifer and Satan were the same person because I did not understand that well. And also, because the characters were very specific to the group, it would have been helpful to add their descriptions beforehand so I wouldn’t have to go searching through the blog for their information/bios/players. Another question I had was about the Church of Saints and Sinners. I’m guessing from the names that the Saints revere the God that died from illness/angels and that the Sinners revere Satan/Lucifer/demons, but this is something that is not made clear in the plot. Or if it was made clear I missed it. You have something really good going for yourself because the plot is very original, but I feel like it was a little confusing to follow or understand some points that are not gone over in much depth. I should be able to understand most if not all the rps components without having to go onto several different pages. However, your powers page helped me gain a lot more understanding with each of the character types and how they fit into the story line. I still think it would be worth it to add short summaries at the beginning of the plot, so if you happen to click the plot first, like I did, you won’t be confused continuing to go through the links. Similar to the power types page, the churches page gives more information, but still I want to know if they worship a specific deity in each of the churches, that is still unclear to me at least. Continuing on, I love this unique style of Events and Tasks you’ve created, as well as the way you’ve developed your point system. I’ve never seen this done before, and I applaud the admins on this idea. Nothing bad to say there. Your page for characters is also very organized and easy to get around. I like the way the page is set up so that the players will have plenty of open opportunity to develop their character because there is no full restricting bio, but the characters still have pieces that make them standout! I can say nothing bad about the characters. I like your use of diversity in faceclaims, both underused and frequently used. 

Let’s talk about the rules and the application. I’ll start with the application, which . For your rules, I think that you should move this rule “Once accepted, please adhere to game canon, including bios, posted information, and your accepted application,” into it’s own bullet point. It doesn’t quite relate to the section before about the OOC blog. I also think it would be nice to move the OOC rules you have on the checklist over to the main rules page anyways (that way it’s note broken up and if it’s left in the checklist it’s just an important restatement of the rules). If more of the OOC rules were on the main rule page, I think it would feel a lot more complete, otherwise all your rules are very clear and helpful to players. I think the application is fine, too, it’s in basic form! 

I’ll wrap this up with the other pages and sidenotes. As for the checklist, it was very nice to include all the needed links. It’s also very organized, but I still think that the OOC rules (and even maybe the IC rules) should just be on the main rule page. That way it keeps everything a bit more organized and, unless you’re restating important information to the players, makes it feel like less information to sort through. This is more of a sidenote, but I see that your main tag to track is just “chvrchesrp”, which makes sense to keep everything in one place, but it’s a personal thought that it might get cluttered with starters, tasks, activities, admin posts, etc., and therefore get very hard to sort through. So, it might be nice and more organized to develop separate tags for specific information. And let me know if I just missed the other tracked tags, but I swear I went through your navigation several times for a page! Otherwise, checklist looks good. I really love the cohesive themes from each of the pages, I think that the locations page is really lovely, the way you set up your masterlist is wonderful, too, and I like the admins page which gives us more detail into you as admins. The only page that I take issue with is the weather page, which while an important detail seems insignificant and like something I, as a player, wouldn’t want to have to go into the navigation to look for it. I’d suggest replacing that page with something else, and just adding another sidebar place with widgets you can just incorporate into your theme. If you end up going through with this idea of moving the widget to another section of the main theme, I can suggest a few websites for that. Otherwise, the worldbuilding you’ve created is relevant (especially with the other blogs of the radio, the musing blog, and so on). This is just another personal sidenote, I think you should call the “customs” tab on the navigation “custom roles”, take it off when the roles are all filled, move the link to the top of the application/rules, or possibly something else? When I first read it I thought it might be some kind of etiquette or traditions section of the blog, but I was surprised to find out that it was actually targeted towards player-created characters.

So, before signing off, I’ll give my final thoughts. I think that this roleplay is fixed up with extremely dedicated admins who have most likely spent days and restless hours trying to formulate each piece of this roleplay. For that, I commend you and congratulate you for keeping a roleplay open for this long and for creating a unique property. The main points I struggled with when going through the blog is just how complicated it seemed and how much information there was. I am the kind of person who gets overwhelmed as a new player if I join in the game a bit late, or it there is already a lot that has happened. So, I think that the plot and the terms and keeping track of all the pages did become a bit engulfing and overpowering. So, I think it would be very, very helpful, if you as admins kept the main page as organized and tidy as possible, it would help new players feel more comforted in joining and allow old players to more easily look through past accomplishments. I had so much that I really didn’t get to talk about in this opinion, but I hope what I focused on helped to organize my thoughts a bit more and got through to the admins.

[loraleislysiren]

Siren Song - 8

For the remainder of the Charms lesson, Draco and Y/N didn’t speak, make eye contact, or interact in any way. Instead, Y/N focused intently on repairing her lilac and gold filigree teapot. Using reparo, she managed to fix her porcelain second quickest in the class. Finishing only behind Hermione, who was indeed still in possession of her wand, Y/N was pleased with her own command of the spell.

The way she figured it, Draco could keep her wand until the end of class. She didn’t need it yet.

Not wanting to tarnish her reputation with her Charms professor, especially after Flitwick had already scolded her for using her magic against Draco, she swiftly formulated a plan to take her wand back after class. Y/N would simply wait until they were out of the classroom and she’d attempt to discretely accio it back. Easy, she hoped.

She wasn’t about to risk getting into further trouble in class, not because of him. He was simply not worth it she decided.

When Flitwick dismissed class, Y/N scanned the room for Blaise. They had Potions together next and he was going to show her how to get there.

Professor Flitwick, however, had no knowledge of, and thus no regard for Y/N’s intentions. He approached the Slytherin student as she was collecting her bag from the chair. “Ms. L/N.”

“Yes, Professor?”

“I’d like to continue working with you on developing your wandless magic. Perhaps pick up where your Ilvermorny instructor left off. Would this be something you’d be interested in?”

Y/N smiled, “Absolutely. I’m definitely interested in that.” A perfectionist through and through, she genuinely wanted to hone her craft. She took pride in the fact that her magical abilities were distinct from her peers, although she was careful not to intentionally brag about it.

“From what I have seen today, you have a particular gift with charms.”

“Thank you. I’ve always loved Charms class and just charms in general.” She spoke honestly.

“I can see that, and you have a real knack for it, it seems. I have a book you might find interesting, and you may borrow it if you like.”

An avid reader, Y/N replied, “I would, sir, thank you.”

“Give me just one moment, and I’ll grab it for you.” Flitwick turned his back on his student, walked to the front of the classroom, and began cycling through the titles of a stack of books taller than himself.

As she waited for Flitwick, Y/N noticed Blaise waiting next to the door with a tall brunette boy she guessed to be Theo. Not sure of how long Flitwick would take, she motioned for them to go ahead and head on without her.

She directed her attention back to her professor who was carefully pulling a dingy salmon colored book from the middle of the stack. Flitwick walked back to Y/N and handed her the book. The pages were gilded and its title read Charmed, Naturally: A Guide for Abandoning the Wand.

“It contains techniques and tips on learning to channel your magic without your wand. You might find some of the advice pertinent to you.”

“Thank you, Professor. I can’t wait to look through it.” She smiled, appreciating his generosity.

“Ms. L/N, just make sure you bring your wand to class next time, just in case. And I hope you have a great day.”

“You too, Professor Flitwick. Thank you.” She turned and exited the classroom.  

As the door behind Y/N shut, a voice spoke up from her right, “That was pretty impressive, you know.” Hermione offered a small smile to the Slytherin girl. “Not just about the wandless magic, which if I might add, I’ve never seen anyone our age do, but also what you did with Malfoy. I didn’t want to say anything in there, but did you see his face? I don’t think he quite expected that.” The brunette’s smile broke into a large grin. She had been waiting for Y/N to exit the classroom so the pair could continue talking.

“I honestly wasn’t expecting it either. I lost it when I saw that he had my wand. Did you see that? He had my wand literally up his sleeve.” She shook her head in annoyance. “He must have taken it out of my bag or something. I knew I had it with me earlier!” She paused, briefly in thought. “But that’s not even what irritates me the most… he was just going to let me get in trouble with Flitwick for something he did, for something that was his fault. ” Y/N exhaled a frustrated sigh.  

“That’s Draco Malfoy for you. A coward who cares about no one but himself.” The Gryffindor’s speech turned hard and unapologetic.

“Yeah, I seem to get that impression. Last night at dinner he told me I wasn’t aloud to sit near him because… “ Y/N hoped Hermione was more openminded than some of her Slytherin compatriots, “because I think the whole ‘blood status matters’ argument is ridiculous. And apparently he cares very deeply about blood purity.” She punctuated the sentence with a roll of her eyes.

Hermione’s eyes, however, momentarily flashed dark; she knew firsthand of Malfoy’s cruel treatment towards muggle borns. “I couldn’t agree with you more. It’s honestly barbaric to think that your blood purity determines your capability as a witch or wizard. It’s insulting. So, are you muggle born?”

“No, but I hope you won’t hold that against me.” Y/N smiled, wanting to change the conversation away from Draco Malfoy and blood purity.

“Not at all.”

“Perfect. Because I’ve got a favor to ask of you.”

“Alright, what would the favor be?” Hermione’s voice was now riddled with trepidation. “Could you possibly help me find my way to the Potions classroom? I was told that Slytherins have Potions with Gryffindors after Charms. I know I’m headed back down to the dungeon, but would you mind if I tagged along with you? If you’re headed that way… ”

Hermione chuckled lightly, “Why do you think I waited for you? Navigating this castle, especially as a new student, can be tricky.” “Yeah, I’m kind of surprised no one gave me a map of the castle. Ilvermorny passes out maps to first years so they don’t get lost. But maybe it’s Hogwarts way of encouraging new students to talk to people.” Y/N smiled at the brunette.

Truth be told, in spite of the warnings about Gryffindors, Y/N was happy to have Hermione’s company. From what little time she had spent with her in Charms and in the hallway, the intuitive Slytherin felt like Hermione was a decent person. At least she seemed more amiable and accepting than her Slytherin roommates. Hermione and Y/N twisted through the castle’s dungeon passages before arriving at the Potions classroom. Y/N pushed open the heavy door, and the girls entered the chilly room.

Stepping just over the room’s threshold and then stopping, Y/N was struck by how different this classroom felt from the rest of Hogwarts. The initial word her mind impressed upon the room was somber. The air was still, stagnant, and to Y/N, seemed almost sepulchral.

Whereas the Charms classroom was airy and inviting (with massive windows filtering in dusty sunlight onto warm wooden floors), the Potions room was dim and slightly oppressive. Light, an enemy to the room, fought through a singular, small window and Y/N couldn’t distinguish if its source was natural or magical. Pallid candles that dripped melting wax dotted the room in a feeble attempt to provide more illumination. Candlelight flickered against the stones walls and low, vaulted dome ceilings. Blackwood shelves, which lined three quarters of the room’s walls, contained hundreds of glass jars of varying sizes. The contents of the jars, marked by labels written in scrawling black ink, contained: dried plants of all designs and colors, pickled animal parts preserved in (yellow, green, and brown) brine, incandescent, iridescent, shimmery bug wings, dried and shriveled beans, herbs, coarse and fine powders, multi-colored liquids, and numerous other ingredients ready to be plucked for the cauldron at a moments notice.

Hermione interrupted Y/N’s cataloguing of the potion ingredients, “Professor Snape assigns us seats. I’d wait to find a seat until he gives you one. Or you could end up taking someone else’s seat, and I don’t think he’d be too happy with that.”

“Thanks for the tip.” She smiled at Hermione as the Gryffindor found her seat. Over the next few minutes, the Potions classroom began to fill with students locating their spots. Y/N wondered who she would sit next to and hoped she wouldn’t be forced to sit alone. At the back of the classroom she noticed an empty table where no one had chanced to sit yet.

“Ms. L/N,” Professor Snape — a monochromatic image of black hair, sallow skin, and black robes — appeared from the shadows of the room.  Had he been standing there all along?

Snape continued and drew the attention of the rest of his students, “We are going to create a Girding Potion today. Are you familiar with it?” He spoke to everyone, yet he addressed the question directly to Y/N.

Y/N, who wasn’t expecting to be interrogated before even finding a seat, hesitated a moment, “A Girding Potion, Professor?”

“Yes, Ms. L/N, a Girding Potion. Are you familiar with it?” Snape leered at the girl, his patience waning by the second.

“I’ve heard of it, but I’ve never made it.”

“And could you enlighten me to its purpose?” Towards the front of the classroom, Hermione’s hand shot straight up in the air.

Y/N articulated, “A Girding Potion is for endurance. It’s like a boost for your stamina, I believe.”

Snape’s face partially softened towards the Slytherin at her correct answer. “Ms. L/N is correct. Five points to Slytherin.”

Snape paced the length of the room as he spoke. “We will be making the Girding Potion today. It is indeed known for bolstering endurance, and a single dosage can last up to two weeks. Known to provide its user with a considerable boost of fortitude, I caution any of you thinking about drinking this potion in large quantities. More than two vials at a time can have detrimental effects.

You will find the list of ingredients and directions on the board, as always. You will be creating this potion individually, but you may discuss the directions with your partner. I will be circling the room providing guidance so none of you burn down,” he stared at Neville Longbottom, “or blow up,” he moved his gaze to Seamus Finnegan, “my classroom.”

Snape looked over his students’ faces, anticipating questions. When none arose, he walked to the back of the room and spoke, “You may begin. You have until the end of class.”

“Ms. L/N,” Snape now stood ten paces in front of Y/N, “you will be working with Mr. Malfoy.” In creeping horror, she realized her professor was standing next to a table with Draco, Crabbe, and Goyle. Was this really happening? Of all the people Snape could have chosen, did it have to be him? Also shocked by Snape’s decision, Draco’s eyes widened and his mouth raced to catch up with his thoughts about his new Potions partner, “But Professor, don’t you think that—“

Snape cut him short, “You see, Ms. L/N, I’ve been generous and let these three,” he rapped on the Slytherin boys’ table, “work together. We had an odd number of students, and now we don’t. That is why Mr. Malfoy,” Snape now turned to Draco, “will sit with you and be your Potions partner.”

“Professor, are you sure?“ Draco, protesting, was desperate for Snape to change his mind. With a slew of reasons popping into his head, Draco knew sitting next to Y/N would be a complicated distraction. “I’m sure there is someone else who would —“

“Do not challenge me, Mr. Malfoy. Your grades are exceptional in my class, and with exception comes privilege. You will help Ms. L/N, is that clear?” Snape’s tone was dry and unyielding.

“Yes, Professor.” Those words were bitter in Draco’s mouth and he had to fight the urge to keep arguing with Snape. He knew he had lost this battle.

Y/N and Draco’s belongings (bags, cauldrons, quills, wands) appeared at the once empty table at the back of the room. The Slytherins took their spots in their new seats.

“Thank you, Professor.” Y/N managed to utter before Snape turned and walked away. The moment Snape was out of earshot, Y/N rounded on the blonde next to her and demanded, “Give me back my wand. Right now.” Her voice was firm, but calm.

Draco, not to be intimidated by a girl much smaller than he was, took a step towards Y/N and closed the distance between the pair considerably. He was still fuming that she had drenched him with water in front of everyone; Draco was use to embarrassing others, not the other way around.  He didn’t handle humiliation well, especially from a blood traitor new girl. There was no way he was going to make this easy for her. “And why would I want to do that?” He taunted her.

“Because it’s not yours. Now give it back to me.”

“Demanding, aren’t we? You’re not even going to say pretty please? Now that’s rude.” Draco sneered at Y/N.

Y/N, not backing down, folded her arms across her chest and stared hard at the boy in front at her. “Give. Me. My. Wand. Or —”

“Or what? What are you going to do? Conjure some more water to drop over my head? Good luck, you’ll earn detention with Snape. He won’t be easy with you like Flitwick was.”

Unfortunately, Y/N believed he was probably telling the truth. She got the impression that her Potions professor wouldn’t tolerate such behavior without substantial punishment. “Maybe I’ll just tell Snape the truth… that you took my wand from me and won’t return it.”

Draco challenged her, “Go ahead, tattle. Do it. Snape won’t believe you. I’m his favorite student. He’ll listen to me any day over you.” Draco was confident in this fact. “Besides, he doesn’t allow wands out anyway. But go ahead, see what happens.”

Y/N was growing irritated. “Seriously? What is wrong with you? Do you think holding my wand hostage is a game? Is it fun for you?”

“Did you think it was fun dropping a ball of water over my head?”

“Yes,” Y/N replied cheekily without hesitation. “But you deserved it.”

Draco took another step closer to her, “Then I think this is great fun. And you deserve it.” The corners of his mouth turned up maliciously. His confidence swelled and he felt like he had regained control over her. Draco knew he had the upper hand against Y/N. “Let’s make a deal, shall we?”  

“How about we skip the deal and you just give me my wand back.” She wanted none of his bullshit bargaining.

“No no no. Where’s the fun in that? You had your fun with me, now it’s my turn.” He paused for a moment, caught up in a thought. “How about this: if you make a better Girding Potion than me, you can have your wand back.”

She narrowed her eyes at Draco and weighed her odds. “Okay. Deal. But, if I win, if my potion is better, not only do I get my wand back, but you don’t ever again get to tell me where I can and can’t sit. Ever.”

Was she really taking this challenge? Draco hadn’t expected her to concede, let demand something else from him if she was victorious. His arrogance got the best of him, though, and Draco accepted, “Fine. But what do I get if I win?”

“What do you want from me?”

Draco could think of a good many things he wanted from Y/N, none of which he particularly wanted to make public to her. His mind raced, he pondered, “How about…” he stalled, then settled firmly on his answer. “A kiss.” His eyes darted to her lips for a half a second.

Y/N wasn’t sure what Draco was going to come up with, but she definitely didn’t think it would be that. He was handsome, but he had been an ass to her. Shocked and caught off guard, Y/N scoffed, “Absolutely not. I’m not kissing you. Choose something else.”      

“Did I say that I wanted you to kiss me? Don’t flatter yourself, L/N.” His voice was a knife, sharp and cutting, and he stressed her last name as if just saying the syllables gave him displeasure. “I would never kiss you.” He knew this was a lie.

“You’ll kiss whoever I want you to kiss, whenever I want you to do it. No house is off limits. I can choose any student I want.” He reveled smugly in his cunningness; he had a plan.

Although Y/N’s better logic warned her to weigh her options more carefully, her pride betrayed her reluctance. She couldn’t attest to how dexterous Draco was at potion making, but she was sure of her own skill. Competitive by nature, Y/N badly wanted to beat him and wipe the smirk off his face. She was use to being underestimated and used this to her advantage, “Fine, Malfoy. It’s a deal.”

Y/N extended her hand to Draco to seal their pact. Draco took her hand in his. Their handshake, which was more like a gentle squeeze, lasted a few awkward seconds longer than either party had anticipated.  

“Alright then,” Draco chided, “you’re on.”

[digital-strategy]

https://ift.tt/2CLEzQ5

User signals!

It’s the one thing SEOs don’t optimize for.

I don’t know why most SEOs ignore this metric considering how important it is to Google.

See, Google doesn’t care to put the website with the most backlinks at the top or the best on page SEO… they want to put the website that you and other people love at the top.

That’s why they look at user signals.

Now, if you aren’t familiar with user signals, check out this experiment by Rand Fishkin that I discussed in a recent article.

It shows that if everyone performed a Google search and clicked on the 4th listing instead of the first one, the 4th skyrockets to the top spot almost instantly.

I’m not saying you should tell your users to click on your listings over the competition. Instead, you should focus on the user. Because if you can make users love your site, then you will rank higher over time.

So, my team and I thought it would be fun to look at the Google Analytics accounts of websites that have never been impacted negatively from a Google algorithm update to see what type of sites Google loves to rank (and their user signals).

By looking at metrics related to the user such as bounce rate, time on site, pageviews per visitors (and 5 other signals), we were able to come up with benchmarks that you should aim for.

We ended up analyzing 518 sites. But before we go into our findings, here are some notes about the data:

Each website had to have been around for at least 3 years. We didn’t look at any brand new websites because they wouldn’t have been around long enough to figure out if Google loved or hated them.

Each website had at least 5,000 monthly visitors a month from Google.

We excluded sites there were in Alexa’s top 1,000 list. Plus we didn’t really have any data we could share from any of those sites.

We exclude any company that was generating over $100,000,000 in revenue. I know that seems high, but we needed a ceiling. When you start looking at data from extremely popular companies, it really skews the data.

We bucketed sites into 10 different categories and we looked at both B2B and B2C sites.

All of the data was gathered using Google Analytics and Google Search Console.

Let’s start.

User signal #1: Bounce rate

You’ve heard the term bounce rate before. And you know that you want to get it as low as possible. But before I get into that, let’s break down the definition:

The percentage of visitors to a particular website who navigate away from the site after viewing only one page.

We found that Google loves sites that have a bounce rate between 26% and 69%:

Based on the type of site you have, you should aim to have a bounce rate as close to (if not better than) the sites above.

If you have a bounce rate that is higher, just follow these 13 steps to help reduce it.

User signal #2: Mobile friendliness

Roughly 60% of all searches take place on a mobile device.

Because more people search Google using a mobile device and due to the fact that they have a mobile-first index, we thought it would be wise to see if sites that are in the good graces of Google have a mobile-friendly site.

As you can see, all 518 sites had a mobile-friendly site. In almost all cases, they didn’t have a “separate” site just for mobile, instead, their website was responsive.

This also makes sense because these days you have to think mobile first when you are designing or creating any website.

If your website isn’t responsive, you should get that fixed ASAP.

And I know some of you are probably wondering about AMP. Most of the sites we looked at were not leveraging the AMP framework as they weren’t all blogs.

User signal #3: Average load time

This is the only metric we didn’t leverage from Google Analytics or Search Console. Instead, we ran each website through Pingdom.

In general, the faster your website loads the better off you are. Why would you want people to have to wait 5 or 10 seconds for your site to load? I know I don’t like waiting.

Google not only uses it as a factor within their algorithm but the slower your site loads the fewer sales you will generate.

If an e-commerce site is making $100,000 per day, a second in load time delay will roughly cost you $2.5 million in lost sales each year.

If you want to improve your load time in the eyes of Google, check out this Page Speed Insights tool that they have. It breaks down exactly what you need to fix.

Don’t worry about getting a perfect score, just get as high as possible.

User signal #4: Percentage of repeat visitors

No one really knows the exact factors Google uses in their algorithm.

And no one has proof if Google is using data from Google Analytics, Chrome, or toolbars (as far as I know). But if I had to guess, I would say there is a high chance they are assuming it is legal.

One of the signals I would look at is repeat visitors. The fact that someone keeps going back to a website tells Google that it has loyalty and people love it.

As you can see from the graph above, websites that have done well on Google have anywhere from 16% to 45% repeat visitors.

When you are starting off, your repeat visitor count is going to be extremely high because it’s going to be you and your friends continually going back to your site.

But as you grow, you’ll notice that it will drop to less than 10%. To get visitors continually coming back to your website, you’ll want to use tools like Subscribers.

It’s a simple tool. It uses browser notifications to get people back to your site.

As you can see from the screenshot above, I used Subscribers to get 42,316 people back to my site 174,281 times.

User signal #5: Percentage of search traffic from brand queries

I’ve blogged about this in the past and have even shown you how my search traffic started to climb as my brand queries grew.

Just as a quick recap, I found that as more people Googled “Neil Patel” or variations of it, Google started to rank my site for other terms like “online marketing.”

Once I learned that brand queries help, I spent more time on building a brand. Now during any given month, I generate roughly 40,412 visitors per month from brand related terms:

I even generate 3,806 brand queries on YouTube:

It’s not just me either. Sites that continually dominate Google also have brand queries as a portion of their search traffic.

And these sites aren’t just getting people to search for their brand, but a high portion of those searches land back to their site. In other words, their brand queries have a high click-through rate.

If you want to dominate Google, you need to build a brand.

The bigger your brand and the more loyal people are to it, the more search traffic you’ll get over time.

If you aren’t familiar with how to build a brand, check out hack number 3 in this article that I recently wrote.

User signal #6: Click-through rate

Speaking of click-through rate, we thought it would be interesting to analyze everyone’s Google Search Console to see the click-through rate these sites had.

Most of these sites had click-through rates between 1.9% and 3.1%.

If your website has a low click-through rate, you can improve it by following these 13 steps.

My best advice is to continually A/B test your title and meta description tag to see if you can make it more appealing so that more people want to click on your search listing as opposed to your competitor’s.

User signal #7: Pageviews per visitor

If someone continually browses your site and visits many pages, you are usually doing something right because it means that people like your content, product, service, or whatever else you are offering.

Of course, you can game the system by writing a really long article and only putting a few hundred words on each page and make people click a “next” button to keep reading more.

But that’s a terrible user experience and you don’t want to do that.

You want people to naturally want to visit tons of pages on your website without having to trick them.

So how many pageviews per visitor do high ranking sites have? Well, here’s the average:

If you want to boost your pageviews per visitor, just follow the tips in this article.

User signal #8: Average time on site

You don’t want people to leave your site… unless they are going to buy something or click on ad.

You want them to stay on your site as long as possible.

As you can see from the chart above, websites that ranked well on Google were able to keep people around for at least 1.6 minutes if not all the way up to 5 minutes.

Now the 5-minute number is going to be a bit tough, but if you can keep people on your site for over 2 minutes you are going to do well.

Plus, you’ll have fewer chances of getting hit by a Google Panda penalty.

This article will teach you how to keep people on your website longer (without tricking them).

Conclusion

To dominate Google, you need to think like Google. It’s not just about gaming the system and tweaking your site so that Google loves you.

It’s more about understanding their main objective, which is to put the user first.

That means that if you also put the user first, in the long run, your rankings should slowly climb.

Now, this doesn’t mean you can ignore normal SEO practices like on-page SEO and link building, but instead, you need to do all of that in parallel with focusing on the user.

So how do your metrics stack up with the benchmarks above?

The post What Do Sites That Have Never Been Penalized by Google Look Like? appeared first on Neil Patel.

via Neil Patel

[alanajacksontx]

An SEO’s survival guide to Single Page Applications (SPAs)

SEOs beware: if you haven’t heard of Single Page Applications (SPA for short), or if you have been resistant to learning about these JavaScript methods for creating websites, the time for hiding your head in the sand is over.

Check out this tweet from Google Webmaster Trends Analyst John Mueller:

The web has moved from plain HTML – as an SEO you can embrace that. Learn from JS devs & share SEO knowledge with them. JS’s not going away.

— John ☆.o(≧▽≦)o.☆ (@JohnMu) August 8, 2017

John Mueller is correct. It’s not going away.

A quick search on Google Trends for “Single Page Application” reveals the sharp rise in popularity and awareness of SPAs over time:

Some developers are positively enamored with using JavaScript frameworks and libraries to create websites, and SPA popularity has been steadily growing.

Take Angular (also known as AngularJS and Angular.js), for example.

Here’s a Google Trends search for the Angular JavaScript framework showing the past 5 years, and Trends even recognizes the application platform – you can see popularity has increased greatly over the last couple of years:

The React JavaScript library shows a similar up and to the right trend:

In my role as a professional SEO, I can’t say that Single Page Applications are the rule and not the exception when it comes to how businesses choose to develop websites these days, but I am running across more and more SPAs, and so are my colleagues.

Yes, it’s true that JavaScript was never intended for web page content delivery.

Yes, it’s true that SPAs to date have not been great for SEO.

Yes, it’s true that many developers who had fun quickly creating websites using SPAs had to later spend more time fixing SEO problems than the time they would have spent if they just coded the site to deliver content via HTML5 in the first place.

But, none of that matters, my SEO friends.

Like it or not, SPAs look like they’re here to stay.

It’s time to stop thinking bad thoughts about SPAs and trying to wish them into the cornfield.

Single-Page Applications: Resistance is futile

I admit it – for a while there I was hoping I could ignore Single Page Applications, and maybe eventually SPAs would end up in the trash heap of obsolete website trends such as the <blink> tag, and web page content that’s free of annoying and intrusive advertising interruptions.

Programming and coding languages live and die by developer adoption. For example, if, by some weird turn of events, developers across the world suddenly decided they hated PHP and fell in love with some super-cool new server-side scripting language, then PHP withers, maybe even dies.

It’s just that simple.

That’s why, for example, Google has been pushing Accelerated Mobile Pages (AMP) super hard – because they need major and widespread developer adoption for AMP to succeed and not wind up as the <blink> tags’ roommate.

Talk to developers who’ve created sites using Angular, React, or other JavaScript frameworks or libraries. See if they light up as they talk about the ease and speed of development and how debugging was not as hard as the rumors have it.

SPAs are popular with developers, and that popularity is not showing any sign of slowing down.

Dipping a toe into the SPA

Looking “under the hood” of SPAs, a distinguishing characteristic is that there’s a lot less back and forth between the server and the browser making requests to the server.

After the initial JavaScript framework download to the browser and first page view, there is no page reloading going on when navigating to a second, third, and fourth (etc.) page, hence the “single page” part of Single Page Application.

After that initial JavaScript framework download and first page view, subsequent pages viewed load very quickly, exactly because of the lack of back and forth requests between the server and browser that “traditional” web sites require.

And this means a very good user experience because no extra page load means no extra wait time. And, as we all know, everyone prefers fast-loading pages.

The main aspect to remember here is that with an SPA there is far less back and forth between the browser and the server.

But JavaScript was never intended for web page content delivery

Before JavaScript started being used commonly in website development, web pages were static and created using HTML.

Using JavaScript enabled website developers to add interactivity to their web pages such as pop-up dialog boxes when a user is filling out a form, expandable content when a user clicks on text or a button, or a drop-down menu when the user hovers their mouse over a navigation element.

These and other user interactive features JavaScript allows can be executed in the browser without requiring a call to the server.

And thus, for many years, website developers used HTML for content delivery, CSS for layout and styling, and JavaScript for adding user interactivity.

It’s a fair generalization that JavaScript has become vital to websites and to a developer’s resume; JavaScript is pretty much ubiquitous. JavaScript is not that difficult to learn compared to full-blown programming languages such as Java and C++. The “J” in AJAX and jQuery is – you guessed it – JavaScript.

I only bring this up because in retrospect, and hindsight is always 20/20, we SEOs all should have seen the rise of Single Page Applications looming on the horizon.

But viewed glass-half-full, the rise of SPAs presents an opportunity for technically-minded SEOs to gain experience and become even more valuable now and in the future.

If SPAs can cause SEO issues, then why do developers create SPA websites?

If you’ve never done any coding, then you might not realize what it’s like to be in a developer’s mindset.

Think about it this way: if you were going to have to sit down and write code to create a certain web page functionality and you could either write 10 lines of code to achieve that, or write 1,000 lines of code, which would you choose? You’d opt for the expedience of 10 lines of code, right?

Developers are not lazy; they simply prefer efficiency and elegance when it comes to writing code. I’ve seen developers frame code and hang it on their office wall. Ever heard the saying “code is poetry?”

If you’re trying to get somewhere the fastest way possible, you take the shortest route, correct?

Single Page Application frameworks and libraries, in crude summary, provide building blocks that allow developers to create a website quickly and efficiently.

Consider the fact that SPAs allow developers to efficiently create modern-looking websites that load pages quickly, which makes for a great user experience, and you can see why you might choose an SPA over coding a website from scratch in HTML, CSS, and JavaScript, or hassling with the constraints of a Content Management System.

SPAs present a fast-loading user experience because they don’t need to reload most resources such as HTML, CSS, and scripts with each user interaction like a “traditional” website does. These files only require initial loading and then after that only new data is retrieved and downloaded from the server.

SPAs reduce response times primarily by moving the heavy-lifting of data processing from the server to the browser.

SEO may be a lesser consideration given the SPA developments upsides, an afterthought, or perhaps not a consideration at all during the website development process. Any SEO pro who has been in digital marketing for very long has seen the all-too-common situation where a company develops a website, only later to ask the question “how do we SEO this thing?”

Not everyone realizes that SEO should be baked-in at the beginning and not sprinkled-on at the end, or that their website development choices can have definite downstream negative impacts with respect to SEO.

JavaScript libraries vs. JavaScript frameworks

Untangling the technology behind SPAs eventually leads us to the topic of JavaScript libraries and frameworks.

Ask a developer “what’s the difference between a library and a framework” and you’ll get a lot of interesting answers.

One overriding distinction you hear repeatedly goes something like this:

The code you write calls a library, whereas a framework calls the code you write.

React and Angular are both SPAs, but React is technically a library, whereas Angular is technically a framework. However, you will hear often people refer to SPA technology generally as “JavaScript frameworks”.

Frameworks can be thought of as a structure, like a pre-fab home which comes with the framing, drywall, plumbing, and electrical wiring and all you have to do is add the appliances, windows and coverings, flooring, paint, etc.

A library can be thought of as a place that contains a set of ready to use pre-built tools and functionalities. You’d call a library in your code for a specific function.

You can see that starting a web development project using frameworks and/or libraries can streamline the process, as opposed to writing from scratch all the necessary code to create a website.

Common SEO problems of Single Page Applications

There’s a lot of talk about how well Google can handle JavaScript when it comes to crawling and indexation.

Crawling and indexing is critical to ranking.

Google discovers web pages using software called Googlebot during a very fast process often called “crawling” or “spidering”, during which it downloads an HTML file it finds, extracts the links and visits them simultaneously, and then sends the downloaded resources to the indexer.

But when it comes to a JavaScript-based single page application website, the process gets a bit more complicated.

It’s like the process noted above, but there’s a delay and extra step involved because part of the indexer must do some heavy lifting by parsing and executing the JavaScript, and the new links found then must be passed back to the crawler to look at and then sent back to the indexer; you can see that this is less efficient because of the JavaScript.

SEO is more than just having “great content” and earning high-quality links; it’s also about making your web pages easy to discover by search engines like Google and making it simple for them to know which pages are more important than other pages via internal linking.

A “traditional” HTML-based site is far easier to crawl and index, and by extension, rank. Google can get all the links easily and see what the importance of pages are via internal linking.

A JavaScript-based SPA website makes Google’s life more difficult, and some testing would seem to indicate that there may be downsides when relying on JavaScript for purposes of indexation.

Google is evidently willing to do the extra heavy lifting here, and to my mind that indicates that they’ll improve over time rather than announce to webmasters in the future that they have decided they don’t want to bother with the extra work required to crawl and index JavaScript-based sites.

Another potential SEO problem related to the extra work to discover links is that Google may have issues with evaluating the link equity of those pages.

It’s likely that in time, at least some of the SPA frameworks in popular use will evolve the rendering process to make it easier for Google to crawl and index, perhaps even making it on par with “traditional” HTML-based websites.

But in the meantime, we’re where we are and those who’ve tested how well Google can handle JavaScript-based sites have shown that Google’s ability is inconsistent, and we’re also still in a place where those who have developed SPAs frequently must use workarounds, for example using prerender.io along with Angular to serve fully-rendered pages to the crawler.

Another solution is isomorphic JavaScript, sometimes called “Universal JavaScript”, where a page can be generated on the server and sent to the browser, which can immediately render and display the page. This solves the SEO issues as Google doesn’t have to execute and render the JavaScript in the indexer.

Headless Chrome is another option recently proposed as an easy solution by a Google engineer, who also mentions another solution called Preact, which ships with server-side rendering.

It’s also a good idea to create a properly formatted XML Sitemap and submit that to Google Search Console.

Right now, there doesn’t appear to be any single solution or a paint-by-numbers approach to handing the problems you may encounter if you’re an SEO assisting a client with launching or redeveloping a website using an SPA.

It boils down to effectively communicating the correct end result that’s needed, and dealing with issues as they’re presented based on the library or framework being deployed.

Some important Single Page Application resources

Some super-sharp SEOs and developers have written helpful articles about Single Page Applications, and here are a few resources I have enjoyed that I think you will find helpful:

Tomasz Rudzki wrote an excellent post here; the title says it all: The Ultimate Guide to JavaScript SEO

Watch this video by Google ‎Senior Webmaster Trends Analyst John Mueller – he provides a terrific general overview of Single Page Applications and how Google treats them

Justin Briggs is quite conversant with both SEO and JavaScript and wrote 2 pieces you should check out: Auditing JavaScript for SEO, and Core Principles of SEO for JavaScript

Richard Baxter wrote this awhile back, but it’s still very much worth your time: The Basics of JavaScript Framework SEO in AngularJS

Will Critchlow shared this excellent post: Early Results from Split Testing JavaScript for SEO

Hold on to your hat when you click on Barry Adams’ JavaScript & SEO: The Definitive Resource List

If you’re a bit short on time, this is an excellent quick read: SEO Considerations for Single Page Applications

I definitely recommend reading this from Angular University: Angular Single Page Applications (SPA): What are the Benefits?

This Microsoft article is not geared to SEOs, but it’s a quick and helpful read: Choose Between Traditional Web Apps and Single Page Apps (SPAs)

This is also a relatively quick read covering a few different SPA types by Johann Wagner

Lastly, I strongly suggest you make time to read this, a very good overview: Single Page Applications: When & Why You Should Use Them

Final thoughts

Single Page Applications are evolving rapidly, as is the web technology landscape in general. It’s worth the effort for professional SEOs to be as conversant as possible with not only Single Page Applications, but also Accelerated Mobile Pages, Progressive Web Apps, Content Management Systems in general, and of course the tech behind how websites are coded from scratch.

My sense of the situation is that SPAs, and Google’s ability to handle JavaScript-based websites, will advance at a quickening pace because the stakeholders involved are aware that SPAs come with a definite SEO downside as it stands right now.

It’s entirely possible that in a year or so the most popular SPAs will ship with SEO solutions built in because awareness of the need for SEO friendly JavaScript-based websites is growing. But there’s no guarantee of that happening soon or at all, so my recommendation for today’s SEOs is to get excited about and embrace this technology trend.

from IM Tips And Tricks https://searchenginewatch.com/2018/04/09/an-seos-survival-guide-to-single-page-applications-spas/ from Rising Phoenix SEO https://risingphxseo.tumblr.com/post/172758142370

[oscarkruegerus]

An SEO’s survival guide to Single Page Applications (SPAs)

SEOs beware: if you haven’t heard of Single Page Applications (SPA for short), or if you have been resistant to learning about these JavaScript methods for creating websites, the time for hiding your head in the sand is over.

Check out this tweet from Google Webmaster Trends Analyst John Mueller:

The web has moved from plain HTML – as an SEO you can embrace that. Learn from JS devs & share SEO knowledge with them. JS's not going away.

— John ☆.o(≧▽≦)o.☆ (@JohnMu) August 8, 2017

John Mueller is correct. It’s not going away.

A quick search on Google Trends for “Single Page Application” reveals the sharp rise in popularity and awareness of SPAs over time:

Some developers are positively enamored with using JavaScript frameworks and libraries to create websites, and SPA popularity has been steadily growing.

Take Angular (also known as AngularJS and Angular.js), for example.

Here’s a Google Trends search for the Angular JavaScript framework showing the past 5 years, and Trends even recognizes the application platform – you can see popularity has increased greatly over the last couple of years:

The React JavaScript library shows a similar up and to the right trend:

In my role as a professional SEO, I can’t say that Single Page Applications are the rule and not the exception when it comes to how businesses choose to develop websites these days, but I am running across more and more SPAs, and so are my colleagues.

Yes, it’s true that JavaScript was never intended for web page content delivery.

Yes, it’s true that SPAs to date have not been great for SEO.

Yes, it’s true that many developers who had fun quickly creating websites using SPAs had to later spend more time fixing SEO problems than the time they would have spent if they just coded the site to deliver content via HTML5 in the first place.

But, none of that matters, my SEO friends.

Like it or not, SPAs look like they’re here to stay.

It’s time to stop thinking bad thoughts about SPAs and trying to wish them into the cornfield.

Single-Page Applications: Resistance is futile

I admit it – for a while there I was hoping I could ignore Single Page Applications, and maybe eventually SPAs would end up in the trash heap of obsolete website trends such as the <blink> tag, and web page content that’s free of annoying and intrusive advertising interruptions.

Programming and coding languages live and die by developer adoption. For example, if, by some weird turn of events, developers across the world suddenly decided they hated PHP and fell in love with some super-cool new server-side scripting language, then PHP withers, maybe even dies.

It’s just that simple.

That’s why, for example, Google has been pushing Accelerated Mobile Pages (AMP) super hard – because they need major and widespread developer adoption for AMP to succeed and not wind up as the <blink> tags’ roommate.

Talk to developers who’ve created sites using Angular, React, or other JavaScript frameworks or libraries. See if they light up as they talk about the ease and speed of development and how debugging was not as hard as the rumors have it.

SPAs are popular with developers, and that popularity is not showing any sign of slowing down.

Dipping a toe into the SPA

Looking “under the hood” of SPAs, a distinguishing characteristic is that there’s a lot less back and forth between the server and the browser making requests to the server.

After the initial JavaScript framework download to the browser and first page view, there is no page reloading going on when navigating to a second, third, and fourth (etc.) page, hence the “single page” part of Single Page Application.

After that initial JavaScript framework download and first page view, subsequent pages viewed load very quickly, exactly because of the lack of back and forth requests between the server and browser that “traditional” web sites require.

And this means a very good user experience because no extra page load means no extra wait time. And, as we all know, everyone prefers fast-loading pages.

The main aspect to remember here is that with an SPA there is far less back and forth between the browser and the server.

But JavaScript was never intended for web page content delivery

Before JavaScript started being used commonly in website development, web pages were static and created using HTML.

Using JavaScript enabled website developers to add interactivity to their web pages such as pop-up dialog boxes when a user is filling out a form, expandable content when a user clicks on text or a button, or a drop-down menu when the user hovers their mouse over a navigation element.

These and other user interactive features JavaScript allows can be executed in the browser without requiring a call to the server.

And thus, for many years, website developers used HTML for content delivery, CSS for layout and styling, and JavaScript for adding user interactivity.

It’s a fair generalization that JavaScript has become vital to websites and to a developer’s resume; JavaScript is pretty much ubiquitous. JavaScript is not that difficult to learn compared to full-blown programming languages such as Java and C++. The “J” in AJAX and jQuery is – you guessed it – JavaScript.

I only bring this up because in retrospect, and hindsight is always 20/20, we SEOs all should have seen the rise of Single Page Applications looming on the horizon.

But viewed glass-half-full, the rise of SPAs presents an opportunity for technically-minded SEOs to gain experience and become even more valuable now and in the future.

If SPAs can cause SEO issues, then why do developers create SPA websites?

If you’ve never done any coding, then you might not realize what it’s like to be in a developer’s mindset.

Think about it this way: if you were going to have to sit down and write code to create a certain web page functionality and you could either write 10 lines of code to achieve that, or write 1,000 lines of code, which would you choose? You’d opt for the expedience of 10 lines of code, right?

Developers are not lazy; they simply prefer efficiency and elegance when it comes to writing code. I’ve seen developers frame code and hang it on their office wall. Ever heard the saying “code is poetry?”

If you’re trying to get somewhere the fastest way possible, you take the shortest route, correct?

Single Page Application frameworks and libraries, in crude summary, provide building blocks that allow developers to create a website quickly and efficiently.

Consider the fact that SPAs allow developers to efficiently create modern-looking websites that load pages quickly, which makes for a great user experience, and you can see why you might choose an SPA over coding a website from scratch in HTML, CSS, and JavaScript, or hassling with the constraints of a Content Management System.

SPAs present a fast-loading user experience because they don’t need to reload most resources such as HTML, CSS, and scripts with each user interaction like a “traditional” website does. These files only require initial loading and then after that only new data is retrieved and downloaded from the server.

SPAs reduce response times primarily by moving the heavy-lifting of data processing from the server to the browser.

SEO may be a lesser consideration given the SPA developments upsides, an afterthought, or perhaps not a consideration at all during the website development process. Any SEO pro who has been in digital marketing for very long has seen the all-too-common situation where a company develops a website, only later to ask the question “how do we SEO this thing?”

Not everyone realizes that SEO should be baked-in at the beginning and not sprinkled-on at the end, or that their website development choices can have definite downstream negative impacts with respect to SEO.

JavaScript libraries vs. JavaScript frameworks

Untangling the technology behind SPAs eventually leads us to the topic of JavaScript libraries and frameworks.

Ask a developer “what’s the difference between a library and a framework” and you’ll get a lot of interesting answers.

One overriding distinction you hear repeatedly goes something like this:

The code you write calls a library, whereas a framework calls the code you write.

React and Angular are both SPAs, but React is technically a library, whereas Angular is technically a framework. However, you will hear often people refer to SPA technology generally as “JavaScript frameworks”.

Frameworks can be thought of as a structure, like a pre-fab home which comes with the framing, drywall, plumbing, and electrical wiring and all you have to do is add the appliances, windows and coverings, flooring, paint, etc.

A library can be thought of as a place that contains a set of ready to use pre-built tools and functionalities. You’d call a library in your code for a specific function.

You can see that starting a web development project using frameworks and/or libraries can streamline the process, as opposed to writing from scratch all the necessary code to create a website.

Common SEO problems of Single Page Applications

There’s a lot of talk about how well Google can handle JavaScript when it comes to crawling and indexation.

Crawling and indexing is critical to ranking.

Google discovers web pages using software called Googlebot during a very fast process often called “crawling” or “spidering”, during which it downloads an HTML file it finds, extracts the links and visits them simultaneously, and then sends the downloaded resources to the indexer.

But when it comes to a JavaScript-based single page application website, the process gets a bit more complicated.

It’s like the process noted above, but there’s a delay and extra step involved because part of the indexer must do some heavy lifting by parsing and executing the JavaScript, and the new links found then must be passed back to the crawler to look at and then sent back to the indexer; you can see that this is less efficient because of the JavaScript.

SEO is more than just having “great content” and earning high-quality links; it’s also about making your web pages easy to discover by search engines like Google and making it simple for them to know which pages are more important than other pages via internal linking.

A “traditional” HTML-based site is far easier to crawl and index, and by extension, rank. Google can get all the links easily and see what the importance of pages are via internal linking.

A JavaScript-based SPA website makes Google’s life more difficult, and some testing would seem to indicate that there may be downsides when relying on JavaScript for purposes of indexation.

Google is evidently willing to do the extra heavy lifting here, and to my mind that indicates that they’ll improve over time rather than announce to webmasters in the future that they have decided they don’t want to bother with the extra work required to crawl and index JavaScript-based sites.

Another potential SEO problem related to the extra work to discover links is that Google may have issues with evaluating the link equity of those pages.

It’s likely that in time, at least some of the SPA frameworks in popular use will evolve the rendering process to make it easier for Google to crawl and index, perhaps even making it on par with “traditional” HTML-based websites.

But in the meantime, we’re where we are and those who’ve tested how well Google can handle JavaScript-based sites have shown that Google’s ability is inconsistent, and we’re also still in a place where those who have developed SPAs frequently must use workarounds, for example using prerender.io along with Angular to serve fully-rendered pages to the crawler.

Another solution is isomorphic JavaScript, sometimes called “Universal JavaScript��, where a page can be generated on the server and sent to the browser, which can immediately render and display the page. This solves the SEO issues as Google doesn’t have to execute and render the JavaScript in the indexer.

Headless Chrome is another option recently proposed as an easy solution by a Google engineer, who also mentions another solution called Preact, which ships with server-side rendering.

It’s also a good idea to create a properly formatted XML Sitemap and submit that to Google Search Console.

Right now, there doesn’t appear to be any single solution or a paint-by-numbers approach to handing the problems you may encounter if you’re an SEO assisting a client with launching or redeveloping a website using an SPA.

It boils down to effectively communicating the correct end result that’s needed, and dealing with issues as they’re presented based on the library or framework being deployed.

Some important Single Page Application resources

Some super-sharp SEOs and developers have written helpful articles about Single Page Applications, and here are a few resources I have enjoyed that I think you will find helpful:

Tomasz Rudzki wrote an excellent post here; the title says it all: The Ultimate Guide to JavaScript SEO

Watch this video by Google ‎Senior Webmaster Trends Analyst John Mueller – he provides a terrific general overview of Single Page Applications and how Google treats them

Justin Briggs is quite conversant with both SEO and JavaScript and wrote 2 pieces you should check out: Auditing JavaScript for SEO, and Core Principles of SEO for JavaScript

Richard Baxter wrote this awhile back, but it’s still very much worth your time: The Basics of JavaScript Framework SEO in AngularJS

Will Critchlow shared this excellent post: Early Results from Split Testing JavaScript for SEO

Hold on to your hat when you click on Barry Adams’ JavaScript & SEO: The Definitive Resource List

If you’re a bit short on time, this is an excellent quick read: SEO Considerations for Single Page Applications

I definitely recommend reading this from Angular University: Angular Single Page Applications (SPA): What are the Benefits?

This Microsoft article is not geared to SEOs, but it’s a quick and helpful read: Choose Between Traditional Web Apps and Single Page Apps (SPAs)

This is also a relatively quick read covering a few different SPA types by Johann Wagner

Lastly, I strongly suggest you make time to read this, a very good overview: Single Page Applications: When & Why You Should Use Them

Final thoughts

Single Page Applications are evolving rapidly, as is the web technology landscape in general. It’s worth the effort for professional SEOs to be as conversant as possible with not only Single Page Applications, but also Accelerated Mobile Pages, Progressive Web Apps, Content Management Systems in general, and of course the tech behind how websites are coded from scratch.

My sense of the situation is that SPAs, and Google’s ability to handle JavaScript-based websites, will advance at a quickening pace because the stakeholders involved are aware that SPAs come with a definite SEO downside as it stands right now.

It’s entirely possible that in a year or so the most popular SPAs will ship with SEO solutions built in because awareness of the need for SEO friendly JavaScript-based websites is growing. But there’s no guarantee of that happening soon or at all, so my recommendation for today’s SEOs is to get excited about and embrace this technology trend.

from Digtal Marketing News https://searchenginewatch.com/2018/04/09/an-seos-survival-guide-to-single-page-applications-spas/

[sheilalmartinia]

An SEO’s survival guide to Single Page Applications (SPAs)

SEOs beware: if you haven’t heard of Single Page Applications (SPA for short), or if you have been resistant to learning about these JavaScript methods for creating websites, the time for hiding your head in the sand is over.

Check out this tweet from Google Webmaster Trends Analyst John Mueller:

The web has moved from plain HTML – as an SEO you can embrace that. Learn from JS devs & share SEO knowledge with them. JS's not going away.

— John ☆.o(≧▽≦)o.☆ (@JohnMu) August 8, 2017

John Mueller is correct. It’s not going away.

A quick search on Google Trends for “Single Page Application” reveals the sharp rise in popularity and awareness of SPAs over time:

Some developers are positively enamored with using JavaScript frameworks and libraries to create websites, and SPA popularity has been steadily growing.

Take Angular (also known as AngularJS and Angular.js), for example.

Here’s a Google Trends search for the Angular JavaScript framework showing the past 5 years, and Trends even recognizes the application platform – you can see popularity has increased greatly over the last couple of years:

The React JavaScript library shows a similar up and to the right trend:

In my role as a professional SEO, I can’t say that Single Page Applications are the rule and not the exception when it comes to how businesses choose to develop websites these days, but I am running across more and more SPAs, and so are my colleagues.

Yes, it’s true that JavaScript was never intended for web page content delivery.

Yes, it’s true that SPAs to date have not been great for SEO.

Yes, it’s true that many developers who had fun quickly creating websites using SPAs had to later spend more time fixing SEO problems than the time they would have spent if they just coded the site to deliver content via HTML5 in the first place.

But, none of that matters, my SEO friends.

Like it or not, SPAs look like they’re here to stay.

It’s time to stop thinking bad thoughts about SPAs and trying to wish them into the cornfield.

Single-Page Applications: Resistance is futile

I admit it – for a while there I was hoping I could ignore Single Page Applications, and maybe eventually SPAs would end up in the trash heap of obsolete website trends such as the <blink> tag, and web page content that’s free of annoying and intrusive advertising interruptions.

Programming and coding languages live and die by developer adoption. For example, if, by some weird turn of events, developers across the world suddenly decided they hated PHP and fell in love with some super-cool new server-side scripting language, then PHP withers, maybe even dies.

It’s just that simple.

That’s why, for example, Google has been pushing Accelerated Mobile Pages (AMP) super hard – because they need major and widespread developer adoption for AMP to succeed and not wind up as the <blink> tags’ roommate.

Talk to developers who’ve created sites using Angular, React, or other JavaScript frameworks or libraries. See if they light up as they talk about the ease and speed of development and how debugging was not as hard as the rumors have it.

SPAs are popular with developers, and that popularity is not showing any sign of slowing down.

Dipping a toe into the SPA

Looking “under the hood” of SPAs, a distinguishing characteristic is that there’s a lot less back and forth between the server and the browser making requests to the server.

After the initial JavaScript framework download to the browser and first page view, there is no page reloading going on when navigating to a second, third, and fourth (etc.) page, hence the “single page” part of Single Page Application.

After that initial JavaScript framework download and first page view, subsequent pages viewed load very quickly, exactly because of the lack of back and forth requests between the server and browser that “traditional” web sites require.

And this means a very good user experience because no extra page load means no extra wait time. And, as we all know, everyone prefers fast-loading pages.

The main aspect to remember here is that with an SPA there is far less back and forth between the browser and the server.

But JavaScript was never intended for web page content delivery

Before JavaScript started being used commonly in website development, web pages were static and created using HTML.

Using JavaScript enabled website developers to add interactivity to their web pages such as pop-up dialog boxes when a user is filling out a form, expandable content when a user clicks on text or a button, or a drop-down menu when the user hovers their mouse over a navigation element.

These and other user interactive features JavaScript allows can be executed in the browser without requiring a call to the server.

And thus, for many years, website developers used HTML for content delivery, CSS for layout and styling, and JavaScript for adding user interactivity.

It’s a fair generalization that JavaScript has become vital to websites and to a developer’s resume; JavaScript is pretty much ubiquitous. JavaScript is not that difficult to learn compared to full-blown programming languages such as Java and C++. The “J” in AJAX and jQuery is – you guessed it – JavaScript.

I only bring this up because in retrospect, and hindsight is always 20/20, we SEOs all should have seen the rise of Single Page Applications looming on the horizon.

But viewed glass-half-full, the rise of SPAs presents an opportunity for technically-minded SEOs to gain experience and become even more valuable now and in the future.

If SPAs can cause SEO issues, then why do developers create SPA websites?

If you’ve never done any coding, then you might not realize what it’s like to be in a developer’s mindset.

Think about it this way: if you were going to have to sit down and write code to create a certain web page functionality and you could either write 10 lines of code to achieve that, or write 1,000 lines of code, which would you choose? You’d opt for the expedience of 10 lines of code, right?

Developers are not lazy; they simply prefer efficiency and elegance when it comes to writing code. I’ve seen developers frame code and hang it on their office wall. Ever heard the saying “code is poetry?”

If you’re trying to get somewhere the fastest way possible, you take the shortest route, correct?

Single Page Application frameworks and libraries, in crude summary, provide building blocks that allow developers to create a website quickly and efficiently.

Consider the fact that SPAs allow developers to efficiently create modern-looking websites that load pages quickly, which makes for a great user experience, and you can see why you might choose an SPA over coding a website from scratch in HTML, CSS, and JavaScript, or hassling with the constraints of a Content Management System.

SPAs present a fast-loading user experience because they don’t need to reload most resources such as HTML, CSS, and scripts with each user interaction like a “traditional” website does. These files only require initial loading and then after that only new data is retrieved and downloaded from the server.

SPAs reduce response times primarily by moving the heavy-lifting of data processing from the server to the browser.

SEO may be a lesser consideration given the SPA developments upsides, an afterthought, or perhaps not a consideration at all during the website development process. Any SEO pro who has been in digital marketing for very long has seen the all-too-common situation where a company develops a website, only later to ask the question “how do we SEO this thing?”

Not everyone realizes that SEO should be baked-in at the beginning and not sprinkled-on at the end, or that their website development choices can have definite downstream negative impacts with respect to SEO.

JavaScript libraries vs. JavaScript frameworks

Untangling the technology behind SPAs eventually leads us to the topic of JavaScript libraries and frameworks.

Ask a developer “what’s the difference between a library and a framework” and you’ll get a lot of interesting answers.

One overriding distinction you hear repeatedly goes something like this:

The code you write calls a library, whereas a framework calls the code you write.

React and Angular are both SPAs, but React is technically a library, whereas Angular is technically a framework. However, you will hear often people refer to SPA technology generally as “JavaScript frameworks”.

Frameworks can be thought of as a structure, like a pre-fab home which comes with the framing, drywall, plumbing, and electrical wiring and all you have to do is add the appliances, windows and coverings, flooring, paint, etc.

A library can be thought of as a place that contains a set of ready to use pre-built tools and functionalities. You’d call a library in your code for a specific function.

You can see that starting a web development project using frameworks and/or libraries can streamline the process, as opposed to writing from scratch all the necessary code to create a website.

Common SEO problems of Single Page Applications

There’s a lot of talk about how well Google can handle JavaScript when it comes to crawling and indexation.

Crawling and indexing is critical to ranking.

Google discovers web pages using software called Googlebot during a very fast process often called “crawling” or “spidering”, during which it downloads an HTML file it finds, extracts the links and visits them simultaneously, and then sends the downloaded resources to the indexer.

But when it comes to a JavaScript-based single page application website, the process gets a bit more complicated.

It’s like the process noted above, but there’s a delay and extra step involved because part of the indexer must do some heavy lifting by parsing and executing the JavaScript, and the new links found then must be passed back to the crawler to look at and then sent back to the indexer; you can see that this is less efficient because of the JavaScript.

SEO is more than just having “great content” and earning high-quality links; it’s also about making your web pages easy to discover by search engines like Google and making it simple for them to know which pages are more important than other pages via internal linking.

A “traditional” HTML-based site is far easier to crawl and index, and by extension, rank. Google can get all the links easily and see what the importance of pages are via internal linking.

A JavaScript-based SPA website makes Google’s life more difficult, and some testing would seem to indicate that there may be downsides when relying on JavaScript for purposes of indexation.

Google is evidently willing to do the extra heavy lifting here, and to my mind that indicates that they’ll improve over time rather than announce to webmasters in the future that they have decided they don’t want to bother with the extra work required to crawl and index JavaScript-based sites.

Another potential SEO problem related to the extra work to discover links is that Google may have issues with evaluating the link equity of those pages.

It’s likely that in time, at least some of the SPA frameworks in popular use will evolve the rendering process to make it easier for Google to crawl and index, perhaps even making it on par with “traditional” HTML-based websites.

But in the meantime, we’re where we are and those who’ve tested how well Google can handle JavaScript-based sites have shown that Google’s ability is inconsistent, and we’re also still in a place where those who have developed SPAs frequently must use workarounds, for example using prerender.io along with Angular to serve fully-rendered pages to the crawler.

Another solution is isomorphic JavaScript, sometimes called “Universal JavaScript”, where a page can be generated on the server and sent to the browser, which can immediately render and display the page. This solves the SEO issues as Google doesn’t have to execute and render the JavaScript in the indexer.

Headless Chrome is another option recently proposed as an easy solution by a Google engineer, who also mentions another solution called Preact, which ships with server-side rendering.

It’s also a good idea to create a properly formatted XML Sitemap and submit that to Google Search Console.

Right now, there doesn’t appear to be any single solution or a paint-by-numbers approach to handing the problems you may encounter if you’re an SEO assisting a client with launching or redeveloping a website using an SPA.

It boils down to effectively communicating the correct end result that’s needed, and dealing with issues as they’re presented based on the library or framework being deployed.

Some important Single Page Application resources

Some super-sharp SEOs and developers have written helpful articles about Single Page Applications, and here are a few resources I have enjoyed that I think you will find helpful:

Tomasz Rudzki wrote an excellent post here; the title says it all: The Ultimate Guide to JavaScript SEO

Watch this video by Google ‎Senior Webmaster Trends Analyst John Mueller – he provides a terrific general overview of Single Page Applications and how Google treats them

Justin Briggs is quite conversant with both SEO and JavaScript and wrote 2 pieces you should check out: Auditing JavaScript for SEO, and Core Principles of SEO for JavaScript

Richard Baxter wrote this awhile back, but it’s still very much worth your time: The Basics of JavaScript Framework SEO in AngularJS

Will Critchlow shared this excellent post: Early Results from Split Testing JavaScript for SEO

Hold on to your hat when you click on Barry Adams’ JavaScript & SEO: The Definitive Resource List

If you’re a bit short on time, this is an excellent quick read: SEO Considerations for Single Page Applications

I definitely recommend reading this from Angular University: Angular Single Page Applications (SPA): What are the Benefits?

This Microsoft article is not geared to SEOs, but it’s a quick and helpful read: Choose Between Traditional Web Apps and Single Page Apps (SPAs)

This is also a relatively quick read covering a few different SPA types by Johann Wagner

Lastly, I strongly suggest you make time to read this, a very good overview: Single Page Applications: When & Why You Should Use Them

Final thoughts

Single Page Applications are evolving rapidly, as is the web technology landscape in general. It’s worth the effort for professional SEOs to be as conversant as possible with not only Single Page Applications, but also Accelerated Mobile Pages, Progressive Web Apps, Content Management Systems in general, and of course the tech behind how websites are coded from scratch.

My sense of the situation is that SPAs, and Google’s ability to handle JavaScript-based websites, will advance at a quickening pace because the stakeholders involved are aware that SPAs come with a definite SEO downside as it stands right now.

It’s entirely possible that in a year or so the most popular SPAs will ship with SEO solutions built in because awareness of the need for SEO friendly JavaScript-based websites is growing. But there’s no guarantee of that happening soon or at all, so my recommendation for today’s SEOs is to get excited about and embrace this technology trend.

from Search Engine Watch https://searchenginewatch.com/2018/04/09/an-seos-survival-guide-to-single-page-applications-spas/