Τι πρέπει να λάβει υπόψη του ένας προγραμματιστής που υλοποιεί τις τεχνικές λεπτομέρειες μιας διαδικτυακής εφαρμογής πριν δημοσιοποιήσει τον ιστότοπο; Αν ο Jeff Atwood μπορεί να ξεχάσει τα HttpOnly cookies, τα sitemaps, και τα cross-site request forgeries όλα στον ίδιο ιστότοπο, ποιο σημαντικό πράγμα θα μπορούσα να ξεχάσω κι εγώ;
Σκέφτομαι αυτό το θέμα από τη σκοπιά ενός web developer, δηλαδή κάποιος άλλος δημιουργεί τον πραγματικό σχεδιασμό και το περιεχόμενο του ιστότοπου. Έτσι, ενώ η χρηστικότητα και το περιεχόμενο μπορεί να είναι πιο σημαντικά από την πλατφόρμα, εσείς ο προγραμματιστής έχετε ελάχιστο λόγο σε αυτό. Αυτό για το οποίο πρέπει να ανησυχείτε είναι ότι η εφαρμογή της πλατφόρμας σας είναι σταθερή, αποδίδει καλά, είναι ασφαλής και ανταποκρίνεται σε τυχόν άλλους επιχειρηματικούς στόχους (όπως να μην κοστίζει πολύ, να μην χρειάζεται πολύς χρόνος για να κατασκευαστεί και να κατατάσσεται τόσο καλά στη Google όσο υποστηρίζει το περιεχόμενο).
Σκεφτείτε το από τη σκοπιά ενός προγραμματιστή που έχει κάνει κάποια δουλειά για εφαρμογές τύπου intranet σε ένα αρκετά αξιόπιστο περιβάλλον και πρόκειται να κάνει την πρώτη του προσπάθεια και να βγάλει έναν δυνητικά δημοφιλή ιστότοπο για ολόκληρο τον μεγάλο κακό παγκόσμιο ιστό.
Επίσης, αναζητώ κάτι πιο συγκεκριμένο από μια αόριστη απάντηση "πρότυπα ιστού". Θέλω να πω, HTML, JavaScript και CSS μέσω HTTP είναι λίγο πολύ δεδομένα, ειδικά όταν έχω ήδη διευκρινίσει ότι είστε επαγγελματίας προγραμματιστής ιστοσελίδων. Οπότε, πέρα από αυτό, Ποια πρότυπα; Σε ποιες περιπτώσεις και γιατί; **Προσφέρετε έναν σύνδεσμο προς τις προδιαγραφές του προτύπου.
Η ιδέα εδώ είναι ότι οι περισσότεροι από εμάς θα πρέπει να γνωρίζουμε ήδη τα περισσότερα από αυτά που περιέχονται σε αυτόν τον κατάλογο. Αλλά μπορεί να υπάρχουν ένα ή δύο στοιχεία που δεν έχετε ψάξει πραγματικά πριν, δεν τα καταλαβαίνετε πλήρως ή ίσως δεν έχετε καν ακούσει ποτέ γι' αυτά. Επαφή και εμπειρία χρήστη
rel="nofollow"
στους συνδέσμους που δημιουργούνται από τους χρήστες για να αποφύγετε το spam.rel="noopener noreferrer"
σε όλους τους συνδέσμους που παρέχονται από τον χρήστη με target="_blank"
για να αποτρέψετε τη JavaScript στη σελίδα προορισμού από το να ανακατευθύνει τη σελίδα σας κάπου αλλού, όπως για παράδειγμα σε μια ψεύτικη σελίδα σύνδεσης. Περισσότερες πληροφορίεςfavicon.ico
στη ρίζα του ιστότοπου, δηλαδή /favicon.ico
. Οι φυλλομετρητές θα το ζητήσουν αυτόματα, ακόμη και αν το εικονίδιο δεν αναφέρεται καθόλου στην HTML. Εάν δεν έχετε ένα /favicon.ico
, αυτό θα έχει ως αποτέλεσμα πολλά 404, εξαντλώντας το εύρος ζώνης του διακομιστή σας.
SEO (Βελτιστοποίηση μηχανών αναζήτησης)example.com/pages/45-article-title
αντί για example.com/index.php?page=45
.#
για δυναμικό περιεχόμενο αλλάξτε το #
σε #!
και στη συνέχεια στον διακομιστή $_REQUEST["_escaped_fragment_"]
είναι αυτό που χρησιμοποιεί το googlebot αντί για #!
. Με άλλα λόγια, το ./#!page=1
γίνεται ./?_escaped_fragments_=page=1
. Επίσης, για τους χρήστες που μπορεί να χρησιμοποιούν FF.b4 ή Chromium, history.pushState({"foo":"bar"}, "About", "./?page=1");
Είναι μια εξαιρετική εντολή. Έτσι, παρόλο που η γραμμή διευθύνσεων έχει αλλάξει, η σελίδα δεν επαναφορτώνεται. Αυτό σας επιτρέπει να χρησιμοποιήσετε το ?
αντί για το #!
για να διατηρήσετε το δυναμικό περιεχόμενο και επίσης να πείτε στον διακομιστή όταν στέλνετε με email τον σύνδεσμο ότι είμαστε μετά από αυτή τη σελίδα, και το AJAX δεν χρειάζεται να κάνει άλλο ένα επιπλέον αίτημα./sitemap.xml
.<link rel="canonical" ... />
όταν έχετε πολλαπλές διευθύνσεις URL που παραπέμπουν στο ίδιο περιεχόμενο, το ζήτημα αυτό μπορεί επίσης να αντιμετωπιστεί από τα Google Webmaster Tools.301 Moved Permanently
) που ζητούν το www.example.com
στο example.com
(ή το αντίστροφο) για να αποφύγετε το διαχωρισμό της κατάταξης στο Google μεταξύ των δύο ιστότοπων.