Edward Hernandez

Shipping a web application to production is the moment everything stops being theoretical. Bugs become incidents, slow queries become customer complaints, and a missing security header can become tomorrow’s post-mortem. At coding4.net, we’ve launched dozens of production applications, and every single one taught us that a solid web application launch checklist is the difference between a calm Tuesday morning and an all-hands firefight. This guide is written for developers, DevOps engineers, and project managers who want a practical, no-fluff list of what to verify before flipping the DNS switch. No marketing platitudes, no “don’t forget to proofread” reminders. Just the technical and operational checks that actually matter in 2026. Why a Pre-Launch Checklist Matters Most launch failures aren’t caused by exotic bugs. They’re caused by forgotten basics: an expired certificate, a missing environment variable in production, a backup job that nobody tested, or a CORS rule that blocks the payment provider. A checklist forces you to slow down and verify the boring stuff that breaks expensive things. The checklist below is split into seven categories so you can assign owners and run it as a gated release process. The 25-Point Web Application Launch Checklist 1. Security Headers and HTTPS Valid SSL/TLS certificate installed with auto-renewal (Let’s Encrypt, ACM, or your CA). Verify expiration date and chain on all subdomains. HSTS enabled with a sensible max-age (start at 6 months, then bump to 2 years once you’re confident). Content Security Policy (CSP) defined and tested in report-only mode before enforcement. Standard security headers set: X-Content-Type-Options: nosniff, Referrer-Policy, Permissions-Policy, X-Frame-Options or frame-ancestors via CSP. Secrets are not in the repo. Verify with a scanner like Gitleaks. Rotate any credential that ever touched a commit history. 2. Authentication and Access Control MFA enforced on admin panels, cloud consoles, CI/CD, and the domain registrar. Rate limiting and brute-force protection on login, password reset, and any public API endpoint. Session and cookie flags correct: HttpOnly, Secure, SameSite. 3. Backups and Disaster Recovery Automated database backups running on a schedule, with retention defined. Restore tested at least once. A backup that has never been restored is a hope, not a backup. Off-region or off-account copy for ransomware and account-compromise scenarios. 4. Monitoring, Logging and Alerting Error monitoring configured (Sentry, Rollbar, Bugsnag, or equivalent) with source maps uploaded for the production build. Uptime monitoring on the homepage, login, and at least one critical API endpoint, from multiple regions. Centralized logs with retention and a search interface. Sensitive fields (passwords, tokens, PII) must be redacted. Alerting routed to a real human, not just an inbox nobody reads. Define on-call rotation if the app is business-critical. 5. Performance and Scalability Lighthouse / Core Web Vitals audit passed on the main public pages. Aim for green LCP, INP, and CLS. Load test executed against a production-like environment using k6, Artillery, or Locust. Know your breaking point before users find it. Caching layers verified: CDN, HTTP caching headers, application cache, database query cache. Database indexes reviewed for the queries that actually run in production. Run EXPLAIN on the slow ones. 6. SEO and Discoverability Basics robots.txt and sitemap.xml deployed and pointing to the canonical domain. Canonical tags, meta titles and descriptions set on every indexable page. Confirm staging is not indexable (no leaked noindex on production, no missing noindex on staging). Open Graph and Twitter Card tags validated with the official debuggers. Analytics installed (GA4, Plausible, PostHog) and consent banner wired correctly for GDPR / ePrivacy compliance. 7. Deployment and Rollback Plan One-command rollback available. Whether it’s a previous Docker tag, a blue/green switch, or a feature flag kill, the team must know exactly how to revert in under 5 minutes. Runbook written and shared: who deploys, who watches dashboards, who communicates with users if something goes wrong, and the exact commands to run. Quick Reference Table Category Owner Tools we recommend Security headers / SSL Backend / DevOps securityheaders.com, SSL Labs, Mozilla Observatory Backups DevOps Native cloud snapshots, restic, pgBackRest Error monitoring Backend + Frontend Sentry, Rollbar, Datadog Performance Frontend + Backend Lighthouse, WebPageTest, k6 SEO basics PM / Frontend Search Console, Screaming Frog, Ahrefs Rollback DevOps Feature flags (Unleash, LaunchDarkly), blue/green deploys What Most Checklists Get Wrong Generic launch checklists tell you to “check your links” and “compress your images”. Useful for a brochure site, useless for a real web application. The items that bite production apps are almost always: An environment variable set in staging but not in production. A cron job, queue worker, or webhook that nobody verified after deploy. An API rate limit on a third-party provider that only triggers at scale. A database migration that locks a table for 40 seconds in production data volumes. A logging library that prints user passwords in clear when an exception bubbles up. Walk through every one of these explicitly, even if it feels paranoid. Launch Day: The 60-Minute Window T-60 min: freeze deploys, announce launch in the team channel, open dashboards. T-30 min: final database backup, verify rollback artifact is ready. T-0: switch DNS / flip feature flag / promote release. T+5 min: smoke test critical user flows manually (signup, login, checkout, key API call). T+30 min: review error rates, latency, and 5xx counts. If anything is off, rollback without ego. T+24 h: post-launch retrospective. Update the checklist with what you missed. FAQ How long before launch should I run this checklist? Start at least two weeks before go-live. Security headers, load tests, and backup restore drills take real time, and you don’t want to discover a blocker the night before launch. Do I really need a rollback plan if I have good tests? Yes. Tests catch known issues. Production catches the unknown ones: traffic patterns, third-party outages, data shapes you never imagined. A rollback plan is your insurance policy. Is this checklist overkill for a small SaaS or MVP? No. Items 1 to 15 are non-negotiable even for an MVP. Skip the load testing and the multi-region backups if you must, but never skip SSL, backups,

Choosing between Flutter and React Native in 2026 is no longer a question of which framework is “better” in absolute terms. Both are mature, both ship production apps used by millions, and both have evolved dramatically in the last three years. The real question is: which one fits your project, your team, and your hiring market? At Coding4, we’ve shipped dozens of cross-platform apps using both stacks. This guide gives you a side-by-side comparison based on what actually matters in 2026: performance, developer experience, ecosystem maturity, and hiring availability. We’ll finish with a clear decision matrix so you can pick with confidence. Quick Verdict: Flutter vs React Native in 2026 Pick Flutter if you need pixel-perfect custom UI, predictable performance across platforms, or you’re targeting mobile + desktop + embedded from one codebase. Pick React Native if your team already knows React/JavaScript, you need deep native integration, or you want to share logic with an existing web app. The State of Both Frameworks in 2026 Flutter in 2026 Flutter is now on version 4.x, with the Impeller rendering engine fully replacing Skia on all platforms. Dart 3.6+ brings macros, improved pattern matching, and meaningful performance gains. Google continues heavy investment, and Flutter has expanded well beyond mobile into web, Windows, macOS, Linux, and embedded systems. React Native in 2026 React Native runs on the New Architecture by default (Fabric renderer + TurboModules + JSI), which eliminates the old asynchronous bridge that historically caused performance bottlenecks. Expo is now the default recommended way to start projects, and the framework benefits from the entire React 19 ecosystem including Server Components patterns adapted for mobile. Performance Benchmarks Performance is the most debated topic, so let’s look at concrete numbers from recent benchmarks (averaged across mid-range Android and iOS devices in 2026): Metric Flutter React Native (New Arch) Cold start time ~1.2s ~1.6s List scroll (10k items) 59-60 FPS 55-60 FPS Animation jank Very low Low (improved with Fabric) App binary size (Android) ~8-12 MB ~6-9 MB Memory usage (idle) Slightly higher Slightly lower CPU-heavy tasks Excellent (AOT compiled) Good (Hermes + JSI) The takeaway: Flutter still has a slight edge on rendering consistency and CPU-bound work because it compiles Dart ahead-of-time to native code. React Native has closed the gap dramatically with the New Architecture and is now performant enough for the vast majority of apps. If your app isn’t a 3D game or a heavy animation showcase, users won’t tell the difference. Developer Experience Language and Learning Curve Flutter (Dart): Strong typing, sound null safety, excellent tooling. Dart is easy to learn but unfamiliar to most developers, which adds onboarding time. React Native (TypeScript): If your team writes React for the web, productivity is nearly immediate. TypeScript is the de facto standard now, giving you type safety similar to Dart. Tooling and Hot Reload Both frameworks offer excellent hot reload. Flutter’s DevTools remain best-in-class for widget inspection and performance profiling. React Native has caught up significantly with the new debugger built on Chrome DevTools and tight Expo integration. UI Development Flutter: Everything is a widget. You get pixel-identical UI on every platform because Flutter draws its own pixels. Great for branded, custom designs. React Native: Uses real native components. UI feels native by default but requires more effort to make perfectly identical across iOS and Android. Ecosystem Maturity Aspect Flutter React Native Package registry pub.dev (50k+ packages) npm (full JS ecosystem) Native module access Platform channels / FFI TurboModules (very fast) Backend by Google/Meta Google Meta + Expo + Microsoft Web support Decent (better for apps than content) React Native Web is excellent Desktop support Stable on Windows, macOS, Linux macOS and Windows via Microsoft Code-push / OTA updates Limited (Shorebird) Mature (EAS Update) React Native wins on raw ecosystem size thanks to npm, while Flutter wins on consistency: most Flutter packages work cross-platform without tweaking. Hiring Availability in 2026 This is where strategic decisions get made, especially for enterprises: React Native developers are easier to hire because any React/TypeScript developer can ramp up in weeks. The talent pool is enormous globally. Flutter developers are growing fast, especially in Europe, India, and Latin America, but the pool remains smaller. Flutter specialists often command similar or slightly higher salaries due to scarcity. Cost of switching: Moving a React web team to React Native is cheap. Moving them to Flutter requires real Dart training. If your company already has a strong React engineering culture, React Native is the path of least resistance. If you’re hiring fresh or building a dedicated mobile team, Flutter is a perfectly viable choice. The Decision Matrix Use this matrix to map your project type to the right framework: Project Type / Constraint Recommended Why Startup MVP, small team, fast iteration React Native (Expo) Fastest setup, OTA updates, easy hiring Brand-heavy app with custom UI Flutter Pixel-perfect identical UI on all platforms Existing React web app needing mobile React Native Code and team reuse Enterprise app, mobile + desktop + web Flutter True multi-platform from one codebase Heavy native SDK integration (BLE, AR, payments) React Native Larger native module ecosystem Game-like or animation-heavy app Flutter Better rendering pipeline (Impeller) Tight hiring market, JS-heavy region React Native Larger talent pool Embedded / kiosk / automotive Flutter Strong embedded support Common Pitfalls to Avoid Choosing based on hype. Both frameworks are excellent in 2026. Choose based on your team and constraints. Underestimating native skills. Whatever framework you pick, you will eventually need someone who understands iOS and Android natively. Ignoring app store rules. Both frameworks pass review easily, but OTA updates have rules. Read them. Picking React Native without Expo. In 2026, bare React Native projects make sense only for very specific cases. Start with Expo. Picking Flutter for content-heavy web. Flutter Web is great for app-like experiences, not for SEO-driven content sites. So, Is Flutter Facing Its End? Short answer: no. Despite occasional rumors and some Google reorganizations, Flutter remains heavily used internally at Google (Google Pay, Google Earth, parts

If your web application is starting to feel sluggish under load, chances are your database is doing too much work. A solid Redis caching strategy can drop response times from hundreds of milliseconds to single digits, while taking pressure off your primary datastore. In this hands-on tutorial, we walk through the three caching patterns you should know (cache-aside, write-through, and write-behind), with real Node.js code, TTL configuration, invalidation tips, and the pitfalls we keep seeing in production at coding4.net. Why Redis for Caching? Redis is an in-memory data store that delivers sub-millisecond reads and writes. It is the default answer when engineers discuss external caching because it is fast, mature, supports rich data structures, and scales horizontally with Cluster or managed services. But Redis alone does not make your app faster, your caching strategy does. What you will learn in this tutorial How to implement cache-aside, write-through, and write-behind in Node.js How to choose TTLs that actually make sense How to invalidate caches without creating stale-data nightmares The most common pitfalls when scaling Redis in production Setting Up Redis with Node.js We will use the official redis client (v4+). Install it along with your favorite framework: npm install redis express Initialize a singleton client you can reuse across your app: // redisClient.js import { createClient } from ‘redis’; const client = createClient({ url: process.env.REDIS_URL || ‘redis://localhost:6379’, socket: { reconnectStrategy: (retries) => Math.min(retries * 50, 2000) } }); client.on(‘error’, (err) => console.error(‘Redis error’, err)); await client.connect(); export default client; Pattern 1: Cache-Aside (Lazy Loading) Cache-aside is the most common Redis caching pattern, especially for read-heavy applications. The application is responsible for talking to both the cache and the database. How it works App requests data and asks Redis first. If found (cache hit), return it. If not found (cache miss), fetch from the database, store it in Redis with a TTL, and return. Node.js implementation import redis from ‘./redisClient.js’; import { db } from ‘./db.js’; const CACHE_TTL = 300; // 5 minutes export async function getProduct(id) { const key = `product:${id}`; const cached = await redis.get(key); if (cached) return JSON.parse(cached); const product = await db.product.findById(id); if (product) { await redis.set(key, JSON.stringify(product), { EX: CACHE_TTL }); } return product; } Pros and cons Pros: Simple, resilient (cache failure does not break writes), cache only contains data actually requested. Cons: First request after a miss is slow, possible cache stampede when many clients miss at once, data can become stale until TTL expires. Pattern 2: Write-Through Write-through is proactive: every write goes through the cache, which then writes to the database synchronously. The cache is always in sync with the database for the data that lives in it. Node.js implementation export async function updateProduct(id, data) { const updated = await db.product.update(id, data); await redis.set( `product:${id}`, JSON.stringify(updated), { EX: 3600 } ); return updated; } When to use it Read-after-write workloads where users expect to see their changes immediately. Data that is read often after being written (user profiles, settings, dashboards). Trade-off: Writes are slightly slower because you pay for two storage operations. You also cache data that may never be read again. Pattern 3: Write-Behind (Write-Back) Write-behind writes to Redis first and asynchronously persists to the database later. It is the fastest option for write-heavy workloads, but the riskiest. Node.js implementation with a queue import redis from ‘./redisClient.js’; import { Queue } from ‘bullmq’; const writeQueue = new Queue(‘db-writes’, { connection: { url: process.env.REDIS_URL } }); export async function recordMetric(userId, metric) { const key = `metrics:${userId}`; await redis.hSet(key, metric.name, metric.value); await redis.expire(key, 86400); await writeQueue.add(‘persist’, { userId, metric }); } A worker consumes the queue and batches writes into the database every few seconds. Perfect for analytics, counters, telemetry, or anything where eventual consistency is acceptable. Comparison table Pattern Best for Consistency Complexity Cache-aside Read-heavy apps Eventual (TTL based) Low Write-through Read-after-write Strong Medium Write-behind Write-heavy, analytics Eventual High TTL Configuration: Pick Numbers, Not Vibes TTL (Time To Live) is the lifespan of a cached entry. The wrong TTL is the number one reason caching strategies fail. Practical TTL guidelines Hot, rarely changing data (catalog, country lists): 1 to 24 hours. User-specific data (profile, cart): 5 to 30 minutes. Volatile data (stock levels, pricing): 10 to 60 seconds, or use explicit invalidation. Session tokens: match the session lifetime exactly. Add jitter to avoid thundering herds If 10,000 keys expire at the same second, they will all hit your database at the same second. Add randomness: const baseTTL = 300; const jitter = Math.floor(Math.random() * 60); await redis.set(key, value, { EX: baseTTL + jitter }); Cache Invalidation: The Hard Part Phil Karlton said it best: there are only two hard things in computer science, and one of them is cache invalidation. Here is how to keep it sane. Strategies that work Delete on write: When data changes, delete the key. The next read repopulates it. Simple and reliable. Versioned keys: Use keys like product:42:v3. Bump the version to invalidate, no DEL needed. Tag-based invalidation: Maintain a Redis Set of related keys, then delete them all when a parent entity changes. Pub/Sub invalidation: In multi-region setups, publish invalidation events so each region clears its local copy. Pattern delete is dangerous Avoid KEYS pattern* in production, it blocks the server. Use SCAN with cursors instead: for await (const key of redis.scanIterator({ MATCH: ‘user:42:*’, COUNT: 100 })) { await redis.del(key); } Common Pitfalls When Scaling Redis in Production 1. Cache stampede When a popular key expires, hundreds of requests miss the cache and hammer the database simultaneously. Mitigations: Lock and refresh: use SET NX as a mutex so only one process refreshes the key. Stale-while-revalidate: serve the old value while a background job refreshes it. Probabilistic early expiration based on remaining TTL. 2. Big keys and hot keys A single 50 MB key or a key receiving 100k ops/sec will bottleneck a node. Split big payloads (use Hashes, paginate), and shard hot keys with suffixes like counter:{shard}. 3. Storing the wrong things Redis is not a

Centering a div is one of those tasks that sounds trivial but has tripped up developers for over two decades. The good news? Modern CSS gives you several reliable ways to do it. In this tutorial, we walk through 6 different methods to center a div horizontally, vertically, or both, with copy-paste code examples and clear guidance on when to use each approach. Quick Comparison: Which Centering Method Should You Use? Method Best For Difficulty Flexbox Most modern layouts Easy CSS Grid Single element centering Very easy Margin auto Horizontal centering of block elements Easy Absolute + transform Overlays, modals, tooltips Medium text-align: center Inline or inline-block content Very easy Line-height trick Single line of text vertically Easy Method 1: Center a Div With Flexbox (Recommended) Flexbox is the most popular and predictable way to center a div both horizontally and vertically. It works in every modern browser and only requires three lines on the parent. .parent { display: flex; justify-content: center; /* horizontal */ align-items: center; /* vertical */ height: 100vh; } .child { width: 200px; height: 200px; background: #4f46e5; } When to use it: Anytime you need to center one or more elements inside a container. This is the go-to method in 2026. Method 2: Center a Div With CSS Grid CSS Grid offers the shortest syntax of them all. With place-items: center, you center children both axes in a single declaration. .parent { display: grid; place-items: center; height: 100vh; } You can also use place-self: center on the child if you only want to center one item in a grid layout: .child { place-self: center; } When to use it: When you want the cleanest possible code, or when your layout is already grid-based. Grid centering options at a glance place-items: centers all children in the grid container place-content: centers the entire grid track place-self: centers a single grid item Method 3: Center a Div Horizontally With Margin Auto This is the classic technique that has worked for over 20 years. It only handles horizontal centering, and the element must have a defined width. .child { width: 400px; margin: 0 auto; } When to use it: For simple horizontal centering of block elements like containers, cards, or article wrappers. It is bulletproof and requires no parent styling. Method 4: Center a Div With Absolute Positioning and Transform This method is perfect for overlays, modals, and tooltips that need to sit on top of other content. .parent { position: relative; height: 100vh; } .child { position: absolute; top: 50%; left: 50%; transform: translate(-50%, -50%); } The trick: top and left at 50% position the top-left corner at the center, then transform: translate(-50%, -50%) shifts the element back by half its own size, achieving true centering even for unknown dimensions. When to use it: Modals, popups, loading spinners, or anything that should be removed from normal document flow. Method 5: Center Inline Content With text-align For inline or inline-block elements (like text, images, or buttons), text-align: center remains the simplest solution. .parent { text-align: center; } .child { display: inline-block; } When to use it: Centering text inside a div, or centering inline-block elements without using Flexbox or Grid. Method 6: Center a Div Vertically With Line-Height If you only need to vertically center a single line of text inside a fixed-height container, the line-height trick is the lightest option. .parent { height: 100px; line-height: 100px; text-align: center; } When to use it: Buttons, badges, or navigation items where the height is known and the content is a single line. Avoid it for multi-line text. Bonus: Centering a Div in Tailwind CSS If you use Tailwind, the Flexbox method becomes a one-liner: <div class=”flex items-center justify-center h-screen”> <div>Centered!</div> </div> Or with Grid: <div class=”grid place-items-center h-screen”> <div>Centered!</div> </div> Common Pitfalls to Avoid Forgetting to give the parent a height: Vertical centering won’t work if the parent has no defined height. Using float for centering: Floats are for wrapping text around elements, not centering. Skip them. Mixing methods unnecessarily: Pick one approach per container to keep your CSS readable. Hardcoding sizes: Whenever possible, let content define the size and let CSS handle alignment. Which Method Should You Pick in 2026? For most cases, use Flexbox or CSS Grid. They are supported by every browser in active use, are predictable, and require minimal code. Reserve absolute positioning for overlays, and use margin auto for simple horizontal centering of fixed-width blocks. FAQ How do I center a div without using Flexbox? You can use margin: 0 auto for horizontal centering, position: absolute with transform: translate(-50%, -50%) for both axes, or CSS Grid with place-items: center. What is the easiest way to center a div in CSS? The easiest way is CSS Grid with display: grid; place-items: center; on the parent. It’s just two lines and works for any child element. How do I center a div both horizontally and vertically? Use Flexbox with justify-content: center and align-items: center, or use Grid with place-items: center. Make sure the parent has a defined height. Why doesn’t margin: auto center my div vertically? Inside a normal block layout, margin: auto only handles horizontal centering. To center vertically with margin auto, the parent must use Flexbox (display: flex). How do I center a div in React? The CSS is identical. Apply your centering styles via a className, inline style, or a CSS-in-JS solution like styled-components. The framework doesn’t change the centering logic. Can I center a div with Tailwind CSS? Yes. Use flex items-center justify-center or grid place-items-center on the parent container. Don’t forget to set a height like h-screen or h-full. Centering a div has never been easier than it is today. Bookmark this guide, copy the snippet you need, and never Google “how to center a div” again.

Why JWT Authentication in Node.js Still Dominates in 2026 If you are building APIs or web applications with Node.js, chances are you need a reliable way to authenticate users. JWT authentication in Node.js remains one of the most widely adopted approaches because it is stateless, scalable, and straightforward to implement. JSON Web Tokens (JWT) let your server verify a user’s identity without storing session data in memory or a database. The token itself carries all the information needed, signed cryptographically so it cannot be tampered with. In this guide, we will walk through every step required to build a production-ready JWT authentication system in Node.js. You will get annotated code examples you can drop into a real project, along with explanations of why each decision matters. What You Will Learn How JWTs work under the hood Setting up a Node.js project with Express User registration and password hashing Generating access tokens and refresh tokens Protecting routes with authentication middleware Implementing a token refresh flow Common security pitfalls and how to avoid them Prerequisites Before we start coding, make sure you have the following ready: Node.js 20+ installed (LTS recommended) A package manager: npm or pnpm Basic knowledge of Express.js A MongoDB instance (local or MongoDB Atlas) or any database of your choice A code editor such as VS Code How JWT Authentication Works: A Quick Overview Before touching any code, let’s understand the flow at a high level. The user sends their credentials (email and password) to the server. The server verifies the credentials against the database. If valid, the server creates a JWT access token (short-lived) and a refresh token (long-lived) and sends both to the client. The client stores the tokens and includes the access token in the Authorization header of every subsequent request. A middleware on the server verifies the token before granting access to protected resources. When the access token expires, the client uses the refresh token to obtain a new one without forcing the user to log in again. Anatomy of a JWT A JSON Web Token is composed of three Base64-encoded parts separated by dots: Part Content Example Fields Header Algorithm and token type alg: HS256, typ: JWT Payload Claims (user data, expiration, etc.) sub, email, iat, exp Signature HMAC or RSA signature of header + payload Used to verify integrity Step 1: Initialize the Project Create a new directory and initialize a Node.js project: mkdir jwt-auth-demo cd jwt-auth-demo npm init -y Install the packages we need: npm install express jsonwebtoken bcryptjs dotenv mongoose cookie-parser Package Purpose express Web framework jsonwebtoken Create and verify JWTs bcryptjs Hash passwords dotenv Load environment variables mongoose MongoDB ODM cookie-parser Parse cookies (for refresh tokens) Step 2: Project Structure Keep things organized from the start. Here is a simple structure that scales well: jwt-auth-demo/ ├── controllers/ │ └── authController.js ├── middleware/ │ └── authMiddleware.js ├── models/ │ └── User.js ├── routes/ │ └── authRoutes.js ├── utils/ │ └── tokenUtils.js ├── .env ├── server.js └── package.json Step 3: Configure Environment Variables Create a .env file in the project root. Never commit this file to version control. PORT=4000 MONGO_URI=mongodb://localhost:27017/jwt-auth-demo ACCESS_TOKEN_SECRET=your_access_token_secret_here_replace_me REFRESH_TOKEN_SECRET=your_refresh_token_secret_here_replace_me ACCESS_TOKEN_EXPIRY=15m REFRESH_TOKEN_EXPIRY=7d Tip: Generate strong secrets with node -e “console.log(require(‘crypto’).randomBytes(64).toString(‘hex’))” Step 4: Create the User Model File: models/User.js const mongoose = require(‘mongoose’); const bcrypt = require(‘bcryptjs’); const userSchema = new mongoose.Schema({ name: { type: String, required: true, trim: true }, email: { type: String, required: true, unique: true, lowercase: true }, password: { type: String, required: true, minlength: 8 }, refreshTokens: [String] // store hashed refresh tokens }, { timestamps: true }); // Hash password before saving userSchema.pre(‘save’, async function (next) { if (!this.isModified(‘password’)) return next(); const salt = await bcrypt.genSalt(12); this.password = await bcrypt.hash(this.password, salt); next(); }); // Compare candidate password with stored hash userSchema.methods.comparePassword = async function (candidatePassword) { return bcrypt.compare(candidatePassword, this.password); }; module.exports = mongoose.model(‘User’, userSchema); Notice we store an array of hashed refresh tokens on the user document. This allows us to invalidate specific tokens later, which is critical for logout and token rotation. Step 5: Token Utility Functions File: utils/tokenUtils.js const jwt = require(‘jsonwebtoken’); /** * Generate an access token (short-lived) */ function generateAccessToken(user) { return jwt.sign( { userId: user._id, email: user.email }, process.env.ACCESS_TOKEN_SECRET, { expiresIn: process.env.ACCESS_TOKEN_EXPIRY } // e.g. ’15m’ ); } /** * Generate a refresh token (long-lived) */ function generateRefreshToken(user) { return jwt.sign( { userId: user._id }, process.env.REFRESH_TOKEN_SECRET, { expiresIn: process.env.REFRESH_TOKEN_EXPIRY } // e.g. ‘7d’ ); } /** * Verify an access token */ function verifyAccessToken(token) { return jwt.verify(token, process.env.ACCESS_TOKEN_SECRET); } /** * Verify a refresh token */ function verifyRefreshToken(token) { return jwt.verify(token, process.env.REFRESH_TOKEN_SECRET); } module.exports = { generateAccessToken, generateRefreshToken, verifyAccessToken, verifyRefreshToken }; Step 6: Authentication Controller This is where the core logic lives: registration, login, token refresh, and logout. File: controllers/authController.js 6a. Register const User = require(‘../models/User’); const bcrypt = require(‘bcryptjs’); const { generateAccessToken, generateRefreshToken, verifyRefreshToken } = require(‘../utils/tokenUtils’); exports.register = async (req, res) => { try { const { name, email, password } = req.body; // Check if user already exists const existingUser = await User.findOne({ email }); if (existingUser) { return res.status(409).json({ message: ‘Email already registered’ }); } // Create user (password hashing happens in the pre-save hook) const user = await User.create({ name, email, password }); // Generate tokens const accessToken = generateAccessToken(user); const refreshToken = generateRefreshToken(user); // Store hashed refresh token const hashedRT = await bcrypt.hash(refreshToken, 10); user.refreshTokens.push(hashedRT); await user.save({ validateBeforeSave: false }); // Send refresh token as httpOnly cookie res.cookie(‘refreshToken’, refreshToken, { httpOnly: true, secure: true, // set to true in production (HTTPS) sameSite: ‘Strict’, maxAge: 7 * 24 * 60 * 60 * 1000 // 7 days }); return res.status(201).json({ accessToken, user: { id: user._id, name, email } }); } catch (err) { return res.status(500).json({ message: ‘Server error’, error: err.message }); } }; 6b. Login exports.login = async (req, res) => { try { const { email, password } = req.body; const user = await User.findOne({ email }); if (!user) { return res.status(401).json({ message: ‘Invalid email or password’ }); } const isMatch =

Why Crawl Errors Matter for Your Website If Google cannot crawl your pages, it cannot index them. If it cannot index them, your pages will never appear in search results. That is why fixing crawl errors in Google Search Console should be a priority for every website owner. Crawl errors signal that Googlebot tried to access a URL on your site and failed. Left unresolved, these errors can hurt your rankings, waste your crawl budget, and create a poor experience for visitors who land on broken pages. In this guide, we will walk you through every type of crawl error you might encounter, show you exactly where to find them in Google Search Console, and give you clear, actionable steps to fix each one. No advanced technical knowledge required. What Are Crawl Errors in Google Search Console? Crawl errors occur when Googlebot attempts to reach a page on your website but cannot load it successfully. Google Search Console reports these errors so you can identify and resolve them before they impact your search visibility. There are two broad categories: Site-level errors – Problems that prevent Google from accessing your entire website (DNS errors, server connectivity issues, robots.txt fetch failures). URL-level errors – Problems affecting specific pages (404 not found, soft 404s, redirect errors, server errors on individual URLs). Google Search Console surfaces these issues primarily through the Pages report (formerly known as the Index Coverage report) and the Crawl Stats report. Understanding both is key to keeping your site healthy. Step 1: Access and Review Crawl Errors in Google Search Console Before you can fix anything, you need to know exactly what is broken. Here is how to find your crawl errors: Log in to Google Search Console. Select the property (website) you want to review. In the left sidebar, click Indexing and then Pages. Look at the section labeled “Why pages aren’t indexed”. This is where Google lists specific error types and the number of affected URLs. Click on any error type to see the list of affected URLs. Additionally, go to Settings > Crawl Stats to see a broader picture of how Googlebot is crawling your site, including response codes and host availability. Pro tip: Export the list of affected URLs for each error type. Having them in a spreadsheet makes it much easier to track your progress as you fix them. Step 2: Fix 404 (Not Found) Errors 404 errors are the most common crawl errors. They occur when Googlebot requests a URL that does not exist on your server. Common Causes of 404 Errors A page was deleted without setting up a redirect. A URL was changed (new slug or permalink structure) without a redirect from the old URL. External sites or internal pages link to a URL with a typo. A product or article was removed from the site. How to Fix Them Determine if the page should still exist. If it was deleted intentionally and has no replacement, a 404 or 410 (Gone) response is actually the correct behavior. Google will eventually drop it from the index. If the content moved to a new URL, set up a 301 redirect from the old URL to the new one. This passes link equity and sends visitors to the right place. If the page was removed but a closely related page exists, redirect the old URL to that related page using a 301 redirect. Fix internal links. Search your site for any links pointing to the broken URL and update them to the correct destination. Contact external sites (if practical). If high-authority sites link to a broken URL, consider reaching out and asking them to update the link. How to Set Up a 301 Redirect The method depends on your platform: Platform Method WordPress Use a plugin like Redirection or Yoast SEO Premium Apache Server Add a rule in your .htaccess file Nginx Server Add a rewrite rule in your server configuration Shopify / Wix / Squarespace Use the built-in URL redirect feature in settings Step 3: Fix Soft 404 Errors A soft 404 happens when a page returns a 200 OK HTTP status code but the content of the page looks like an error page to Google. In other words, the server says “everything is fine” but the page is essentially empty or displays a “page not found” message. How to Fix Them If the page truly does not exist, make your server return a proper 404 or 410 HTTP status code instead of 200. If the page exists but has thin content, add meaningful, unique content to the page so Google no longer considers it empty. Check your CMS settings. Some content management systems serve custom 404 pages with a 200 status code. Verify that your custom error page actually sends the correct 404 header. Step 4: Fix Server Errors (5xx) Server errors (HTTP 500, 502, 503, etc.) mean that Googlebot reached your server, but the server failed to deliver the page. These are serious because they can affect your entire site if they happen frequently. Common Causes Your server is overloaded or running out of resources. A misconfigured server-side script or plugin is crashing. Your hosting provider is experiencing downtime. Database connection failures. Timeout errors due to slow page generation. How to Fix Them Check your server logs. Look at the error logs on your hosting account or server. The logs will tell you exactly which script or process is failing and why. Test the affected URLs yourself. Try loading them in a browser. If they work for you, the error may be intermittent. Use the URL Inspection tool in Google Search Console to see exactly what Googlebot encountered. Review recent changes. Did you recently update a plugin, theme, or server configuration? Roll back changes if errors started after an update. Upgrade your hosting if needed. If traffic spikes cause 503 errors, your server may not have enough resources. Consider upgrading to a more powerful hosting plan or adding caching (e.g., Cloudflare,